Today I’ve come across two things with CPF 2.4 that is a bit problematic.
WGATray. It sometimes wants to dial out when I start Windows XP. I’ve always clicked “Deny”, but not set up any rule. Today I clicked “Remember”. This created a rule which I found very strange, see the posted image below. WGATray wasn’t even mentioned in the rule, only svchost.exe and services.exe. I don’t want to block those programs, as I know they might be important for the system to work. But I do whish to block WGATray* independent of those two programs. Impossible?
Browser “injection”. I had to reinstall Ghostscript, for a certain reason. When this was done, I decided to start Firefox. But for some reason a installer temp file (related to Ghostscript) wanted to access the net, see image below. I clicked “Deny”. Then it was impossible to access the net. Why does it work this way? Why can’t Comodo just block that temp file, and let me use Firefox as usual? Besides, something strange happened - I deleted this temp file, but the same thing kept happen, until I restarted the system. I don’t get it, I did clean up the folder where the temp file was located, but still Comodo alerted when I started Firefox.
In the 3.0 alpha, has anyone noticed a more convenient handling of the matters above? Simply, block a “child” but keep letting the “parents” access the net?
(* = Why do I want to block it? Not because my XP is illegal. My XP is genuine. But, it’s a principle, I don’t think WGATray should have the right to “spy” on me, on every system startup. Only when I update Windows or download MS programs, I can accept to validate my copy of Windows.)
You may have to create a rule manually for WGATray.exe, since it will probably use (and show up as) svchost.exe.
Simply open Application Monitor, click Add, and create the rule as:
Application: WGATray.exe (browse to c:\windows\system32 - that’s where it is)
Parent: Skip or Learn
Action: Block
Protocol: TCP/UDP
Direction: Out
Just be aware that when you want to Update Windows, if WGA is needed, you may have to unblock the application (you may not need to do anything; wgatray may not be needed for that - just covering the bases).
For the injection issue. Wow, I can’t believe you have never had this before! The browser is blocked because you chose to deny the alert. This tells Comodo that your computer must have been compromised by malware (because you denied the connection) so it blocks both applications to make sure you are secure. Blocking without remember keeps it in memory only for that session.
In most cases, restarting the browser application is sufficient to clear out the block on itself. In some cases, however (mostly OLE alerts, in my experience) a reboot is required to clear it and reset everything. This can be annoying, yes. The trade-off (at present) is decreased security; what if it had been a malware instead of a legitimate application? Then I promise you would be very happy it blocked everything…
As to v3, yes I think it does a “better” job, where “better” equals “quieter.” I cannot attribute this to the expanded safelist yet, as it is not in the Alpha. So it must be a change in the way it handles such things.
As for the injection, I’ve had it before, but I only allow it for a minimal list of programs, like svchost, Comodo, G. Earth, Pidgin… only the very essential ones. Once I had AutoCAD (several months ago), and exactly the same thing happened; a DLL constantly wanted to inject itself into IE, so I was forced to allow it. Exactly the same for RocketDock, which we discussed a long time ago. The rules of blocking those DLLs were not remembered by Comodo, which I posted I ticket for.
You confirm exactly what I thought, but still, I would prefer that Comodo blocked only the injected file, not the browser. For example, if I run OpenOffice.org and IE (or Firefox, don’t remember which one - or both), it will inject something to check for updates. Sure, I trust the authors of OpenOffice, but still whish to block - and then the browser “dies” until it is restarted… as you probably know.
The fact that a temp file (.exe) from Ghostscript tried to inject itself, must have been some kind of memory bug. Again, it was deleted, but not from CPF’s point of view…
So, it’ll be interesting what v 3 is up to! (it still feels like a dream to have today’s best firewall for free, and meanwhile wait for an even better one…)
LeoniAquila, I fear you don’t understand the situation.
It doesn’t make much sense to block an application that doesn’t itself want to access the net in the first place (like your temporary .exe file).
Also there is nothing injected into Firefox, it’s just some messages sent to Firefox that might cause it to connect to some website or change it’s user interface or whatever.
However, a firewall has no way of knowing which connections are initiated by Firefox because of the messages sent from another application, and which connections are initiated by Firefox because you the user wanted Firefox to do so (like when you click a link or type an URL).
So there are only 2 options: 1) allow Firefox to continue to access the net or 2) block Firefox after those messages were detected. The only thing that could be improved is that the Firewall should “forget” the “non-remember” block of Firefox once Firefox is re-started (in a new process). Only I don’t know if that would be 100% safe for all applications. Probably not. A solution to this would be to have 3 options: a) remember b) remember only for this session c) remember only for this process.
In other words: “blocked only the injected file, not the browser” like you phrase it is just something that isn’t possible.
I still think it makes sense. For example, a similar scenario happens when you uninstall some programs - the uninstaller sends a message to Firefox, to open a page where you can tell the software maker why you uninstalled it. You’re right about the injections thing, that’s a little different - even though I would like to handle it in the same way. I would still like to block those messages from making Firefox accessing the net, not Firefox itself, which is the consequence of CPF’s handling here.
This seems to be a contradiction. It appears to me that the firewall actually knows everything that happens. If it detects that a connection is initiated by a message, then it warns. If a connection is initiated from a link, it does not warn, because there is a rule of allowing Firefox - but not that temp.exe file which sent the message.
So I do think this should be possible. Imagine you have an exe somewhere that constantly keeps sending messages to Firefox. Why does CPF have to block both Firefox and the exe? Similar, if a DLL is injected and I block it - why doesn’t Firefox have access anymore?
I don’t think this is a bug, but it’s kind of functionality, which I wish was different.
The exe is trying to make contact with the help of firefox. The exe file can’t connect on it’s own. So to block the exe file, firefox must be blocked.
Would be nice if CPF could only block the specific file, but I don’t think that it’s possible right now.
