I use GW 2.1.24, Vista Ultimate 32b, and a good personal firewall.
The firewall has identified the following types of indirect network access by GoWrite:
- write to application's memory
- inject dll
- send message
- global variable
The latter one or two (especially the last one) might also be used by the Windows environment (e.g., in case of copy&paste or file association).
However, I wonder which of the types are intended by the programmer, which are necessary, and which are used to communicate with javaw.exe?
The funny thing is, blocking the first three types does not seem to have an effect (so far) on GoWrite's functionality (except for the not terminated multiple instances, see the other thread). So why should one allow those types of indirect network access at all? (Indirect basically means: via another program, e.g., javaw.exe.)
GoWrite is not supposed to be an online program. So in prinicple I want to prohibit all network activity. This is not easy because I need to enable javaw.exe for CGoban. What is the best way to protect myself against internet access of GoWrite (or third softwares possibly abusing GoWrite)?
Indirect Network Access
Moderator: lpaatero
Re: Indirect Network Access
Hi,
These operations are not network related in any sense. All of them are rather normal windows program behavior. I cannot remove causes to them, and they have nothing to do with network access.
GOWrite does no network access at all, except in one very specific case: GOWrite can downloading SGF file from URL, if proper switch and URL are given in commandline.
So messages as such does not make sense. I guess firewall is attempting to use some ridiculous heuristics to detect unknown malware based on software behaviour. This kind of heuristics are prone to false detections, and most firewalls do only very limited attempts in them due to false detections.
What firewall product you are using?
I would like to check information about it.
regards
Lauri Paatero
These operations are not network related in any sense. All of them are rather normal windows program behavior. I cannot remove causes to them, and they have nothing to do with network access.
GOWrite does no network access at all, except in one very specific case: GOWrite can downloading SGF file from URL, if proper switch and URL are given in commandline.
So messages as such does not make sense. I guess firewall is attempting to use some ridiculous heuristics to detect unknown malware based on software behaviour. This kind of heuristics are prone to false detections, and most firewalls do only very limited attempts in them due to false detections.
What firewall product you are using?
I would like to check information about it.
regards
Lauri Paatero
Re: Indirect Network Access
>> These operations are not network related in any sense. <<
Presumably not, but the problem is: The user has to believe the programmer.
>> I guess firewall is attempting to use some ridiculous heuristics to detect unknown malware based on software behaviour. <<
Those heuristics are not ridiculous but they prevent malware M attacks that use indirect types of communication with a real network program N (like javaw.exe). Since a firewall cannot judge about the contents of communcation between M and N, it needs to either allow or prohibit the communication per se (on request of the PC user). GoWrite and a malware M use the same types of communication. So the firewall cannot know if the contents from GoWrite to N is any less harmful than the contents from M to N.
>> most firewalls do only very limited attempts in them due to false detections. <<
That is why many of them fail to detect many malwares at all.
>> What firewall product you are using? <<
Jetico Personal Firewall 2.
***
Anyway, it would be nice really if you stated the intended and the necessary types of communication, and which of them are used to communicate with javaw.exe.
Presumably not, but the problem is: The user has to believe the programmer.
>> I guess firewall is attempting to use some ridiculous heuristics to detect unknown malware based on software behaviour. <<
Those heuristics are not ridiculous but they prevent malware M attacks that use indirect types of communication with a real network program N (like javaw.exe). Since a firewall cannot judge about the contents of communcation between M and N, it needs to either allow or prohibit the communication per se (on request of the PC user). GoWrite and a malware M use the same types of communication. So the firewall cannot know if the contents from GoWrite to N is any less harmful than the contents from M to N.
>> most firewalls do only very limited attempts in them due to false detections. <<
That is why many of them fail to detect many malwares at all.
>> What firewall product you are using? <<
Jetico Personal Firewall 2.
***
Anyway, it would be nice really if you stated the intended and the necessary types of communication, and which of them are used to communicate with javaw.exe.
robert jasiek
Re: Indirect Network Access
Hi,
All of these events are normal in GOWrite (as fas as firewall message is what I think it is). If you would understand the terms firewall is using, you would know that messages do not indicate attempt in network activity. In short: your firewall is mis-guiding you here.
Here you have really only 3 options:
BTW, firewalls fail to detect malware mainly because malware authors test their malware with large number of firewall products. So they can modify their malware code until heuristics do not anymore detect it.
regards
Lauri Paatero
All of these events are normal in GOWrite (as fas as firewall message is what I think it is). If you would understand the terms firewall is using, you would know that messages do not indicate attempt in network activity. In short: your firewall is mis-guiding you here.
Here you have really only 3 options:
- * Accept warning when using GOWrite.
* Don't use GOWrite.
* White-list GOWrite regarding there warning, or turn warnings off some other way.
BTW, firewalls fail to detect malware mainly because malware authors test their malware with large number of firewall products. So they can modify their malware code until heuristics do not anymore detect it.
regards
Lauri Paatero
Re: Indirect Network Access
>> would know that messages do not indicate attempt in network activity <<
I am aware that indirect access to another program is not network activity yet. It requires a process chain
program M -> indirect communication -> program N -> (etc.) -> access to network -> outbound communication
>> In short: your firewall is mis-guiding you here. <<
This is deliberate so that the firewall user is aware that a trusted program N may be sending malicious data from M provided indirect access M -> N was allowed.
>>
Here you have really only 3 options:
[list]* Accept warning when using GOWrite.
* Don't use GOWrite.
* White-list GOWrite regarding there warning, or turn warnings off some other way.
[/list]
<<
Yes.
>> how can they tell which one is false and which is not, when most are false? <<
For an experienced Windows user, it is comparatively easy to minimize the number of warnings that are difficult to decide. Anyway, I am currently not having warnings because it is all already in the firewall rules.
***
However, among the 60 or 70 non-internet programs I am using, only two are remaining suspicious: GoWrite and some other but old program not behaving perfectly under Vista any more. This should motivate you to reflect the degree of severity with respect to security that GoWrite poses to the user. You won't hear complaints from other users because most users simply don't think much about security. E.g., in a recent sample, I was the only one of 170 persons to disable JavaScript in my browser by default, although it is a reasonably well known security hole. Since you rely on a programming platform capable of internet communication (JRE), you should all the more design communication carefully with respect to security - even if I might be the only one to remind you...
***
In general, programmers of go softwares have shown a too low concern for security so far. This is very unfortunate. What about taking pride in offering the first non-open-source software where security plays a key role?
I am aware that indirect access to another program is not network activity yet. It requires a process chain
program M -> indirect communication -> program N -> (etc.) -> access to network -> outbound communication
>> In short: your firewall is mis-guiding you here. <<
This is deliberate so that the firewall user is aware that a trusted program N may be sending malicious data from M provided indirect access M -> N was allowed.
>>
Here you have really only 3 options:
[list]* Accept warning when using GOWrite.
* Don't use GOWrite.
* White-list GOWrite regarding there warning, or turn warnings off some other way.
[/list]
<<
Yes.
>> how can they tell which one is false and which is not, when most are false? <<
For an experienced Windows user, it is comparatively easy to minimize the number of warnings that are difficult to decide. Anyway, I am currently not having warnings because it is all already in the firewall rules.
***
However, among the 60 or 70 non-internet programs I am using, only two are remaining suspicious: GoWrite and some other but old program not behaving perfectly under Vista any more. This should motivate you to reflect the degree of severity with respect to security that GoWrite poses to the user. You won't hear complaints from other users because most users simply don't think much about security. E.g., in a recent sample, I was the only one of 170 persons to disable JavaScript in my browser by default, although it is a reasonably well known security hole. Since you rely on a programming platform capable of internet communication (JRE), you should all the more design communication carefully with respect to security - even if I might be the only one to remind you...
***
In general, programmers of go softwares have shown a too low concern for security so far. This is very unfortunate. What about taking pride in offering the first non-open-source software where security plays a key role?
robert jasiek
Re: Indirect Network Access
Here is some more specific information on apparently needed indirect access / process:
Allow send_message from GoWrite.exe to GoWrite.exe.
I am still testing whether send_message or write_to_other_application's_memory are needed for javaw.exe. However, the above rule is already a great restriction: All third destination applications (possibly excluding javaw.exe) can be blocked! I.e., you do not need to allow
Allow send_message from GoWrite.exe to any application.
File association and immediate GoWrite window popup will still work with the first rule above.
Needless to say, GoWrite.exe creates javaw.exe as a child process, however, it does not modify it (in case your firewall should make that distinction at all!).
***
If you use a different application that is an online go client and also uses javaw.exe, you can separate it even more strictly from GoWrite by copying javaw.exe to a different directory and using the copy for the other application. For further details, see Sensei's Library.
Allow send_message from GoWrite.exe to GoWrite.exe.
I am still testing whether send_message or write_to_other_application's_memory are needed for javaw.exe. However, the above rule is already a great restriction: All third destination applications (possibly excluding javaw.exe) can be blocked! I.e., you do not need to allow
Allow send_message from GoWrite.exe to any application.
File association and immediate GoWrite window popup will still work with the first rule above.
Needless to say, GoWrite.exe creates javaw.exe as a child process, however, it does not modify it (in case your firewall should make that distinction at all!).
***
If you use a different application that is an online go client and also uses javaw.exe, you can separate it even more strictly from GoWrite by copying javaw.exe to a different directory and using the copy for the other application. For further details, see Sensei's Library.
robert jasiek
Re: Indirect Network Access
When I close GoWrite, then the process of GoWrite and its child jawaw.exe are still active. Why are they not terminated properly? Is this a bug or can I alter my firewall settings?
There is some relation to the firewall: If I prohibit some kinds of indirect network access, then each instance of GoWrite (and its child) remains active as a process. If I allow all kinds of indirect network access, then only one instance remains active as a process after GoWrite was closed by the user.
There is some relation to the firewall: If I prohibit some kinds of indirect network access, then each instance of GoWrite (and its child) remains active as a process. If I allow all kinds of indirect network access, then only one instance remains active as a process after GoWrite was closed by the user.
Re: Indirect Network Access
As the programmer explained to me, it is feature (not a bug) of GW to remain active as a process (for some time) after closing the GUI, so that GW can be opened again faster. I dislike this feature, but, as long as it exists, we need to act accordingly.
I do not know if GW itself has any direct network access, but it uses java or javaw or javaws, which are, in principle, capable of network access. Things are easy if you do not use any other program relying on Java to access the internet, but the KGS client CGoban does use it. Then, solutions for blocking the GW-related Java processes from accessing the internet become tricky.
Under Windows, I do the following. I apply my security concept:
http://home.snafu.de/jasiek/windows_sec ... ncept.html
In particular, I use the different users MyPrivateUser and MyOnlineUser. GW I use only under MyPrivateUser, while CGoban I use only under MyOnlineUser.
Software Restriction Policies allow GW under MyPrivateUser and prohibit it under MyOnlineUser and allow CGoban under MyOnlineUser and prohibit it under MyPrivateUser. As I use 64b Windows 7 Pro, I use 64b-Java for GW and 32b-Java for CGoban. This coincidence allows me to apply Software Restriction Policies also to the 64b and 32b versions of Java accordingly. Furthermore, I copy the javaw.exe to the CGoban program direction so that Software Restriction Policies can specifically allow this instance of Java for CGoban under MyOnlineUser. However, if you do not use a Professional (etc.) edition of Windows, then you need to be an expert to set Software Restriction Policies for specific user accounts and specific programs manually by registry hacks.
User deactivation of the network hardware under MyPrivateUser, access rights and integrity levels contribute to the fun of realising the security concept.
As you can see, I do not solve the security problem by the firewall, but I solve it with other security features. If you still want to solve it (also) by your firewall, you must either accept that the GW processes continue to run and set firewall rules accordingly, find some (Sysinternals?) tool that kills the processes on closure of the GUI windows or convince the programmer to do so.
I do not know if GW itself has any direct network access, but it uses java or javaw or javaws, which are, in principle, capable of network access. Things are easy if you do not use any other program relying on Java to access the internet, but the KGS client CGoban does use it. Then, solutions for blocking the GW-related Java processes from accessing the internet become tricky.
Under Windows, I do the following. I apply my security concept:
http://home.snafu.de/jasiek/windows_sec ... ncept.html
In particular, I use the different users MyPrivateUser and MyOnlineUser. GW I use only under MyPrivateUser, while CGoban I use only under MyOnlineUser.
Software Restriction Policies allow GW under MyPrivateUser and prohibit it under MyOnlineUser and allow CGoban under MyOnlineUser and prohibit it under MyPrivateUser. As I use 64b Windows 7 Pro, I use 64b-Java for GW and 32b-Java for CGoban. This coincidence allows me to apply Software Restriction Policies also to the 64b and 32b versions of Java accordingly. Furthermore, I copy the javaw.exe to the CGoban program direction so that Software Restriction Policies can specifically allow this instance of Java for CGoban under MyOnlineUser. However, if you do not use a Professional (etc.) edition of Windows, then you need to be an expert to set Software Restriction Policies for specific user accounts and specific programs manually by registry hacks.
User deactivation of the network hardware under MyPrivateUser, access rights and integrity levels contribute to the fun of realising the security concept.
As you can see, I do not solve the security problem by the firewall, but I solve it with other security features. If you still want to solve it (also) by your firewall, you must either accept that the GW processes continue to run and set firewall rules accordingly, find some (Sysinternals?) tool that kills the processes on closure of the GUI windows or convince the programmer to do so.
robert jasiek
Re: Indirect Network Access
Hi,
EDIT: It seems possible that tufail123 is actually spammer, just combining different texts already in board. tufail123: If I am wrong, please respond!
regards
Lauri
This is to speed up next start. Very often users start gowrite immediately after closing it. Gowrite should terminate itself in few minutes.tufail123 wrote:When I close GoWrite, then the process of GoWrite and its child jawaw.exe are still active. Why are they not terminated properly? Is this a bug or can I alter my firewall settings?
It seems you are preventing gowrite instances from seeing each other. And as they cannot see each other, they will start multiple copies. This is not good, as it prevents some features from working properly (such as game database).tufail123 wrote:There is some relation to the firewall: If I prohibit some kinds of indirect network access, then each instance of GoWrite (and its child) remains active as a process. If I allow all kinds of indirect network access, then only one instance remains active as a process after GoWrite was closed by the user.
EDIT: It seems possible that tufail123 is actually spammer, just combining different texts already in board. tufail123: If I am wrong, please respond!
regards
Lauri