Hello guys!
I would like to show you another hole for a leak.
This leaktest is called CDFIRLZ-Leaktest, that means: Comodo Don’t Filter Incoming Requests to Loopback Zone.
At first I want to tell that it is not only Comodo leak, it is also a browser leak. Some well-known browsers don’t filter outgoing queries to loopback zone. But not all browsers, for example the last version of Opera is safe for this leak.
I have:
Enable alerts for loopback requests.
Global Rule: Block all incoming connections to loopback zone.
Application Rule for CDFIRLZ-Leaktest.exe: Block all IN and Out connections.
Firewal Mode: Custom Policy.
Defense+ Mode: Safe Mode or Paranoid Mode.
Sandbox Security Level: Disable or Enable.
CDFIRLZ-Leaktest.exe doesn’t have administrative privileges and is not in the TFL.
As a result Comodo Firewall (5.9.219863.2196) has FAILED the test. With Comodo 3 browsers(Internet Explorer, Mozilla Firefox, Google Chrome) have FAILED the test. Certainly there were the default settings for these browsers. And maybe with intelligent settings these browsers will have passed the test. But what user think about this? As to me I also didn’t know about this hole for the leak before.
If Comodo would filter incoming requests to loopback zone then even if browser have a hole Comodo will close this hole and will prevent the leak.
At present time, the solution is to disable explicitly outgoing connections for all applications which surf the web(except Opera of course :-)). At first it concern browsers. But of course this must be a temporal decision because it is a very bad. Requests to loopback zone are needed for some aims. For example Tor’s proxy connections, Webmoney authorization(electronic payment system), development of web-applications and others. That’s why the ideal solution is: the vulnerable browsers must close this hole for the leak (like in Opera, for example) and Comodo must also filter incoming requests to loopback zone.
I have not tested it but have a strict configuration for this.
I think your talking about the following situation here.
Your browser is running and tries to connect to an other application on your system by using the loopback interface and could ‘leak’ via that channel to the internet provided the abuse application has access to internet right?
Say I have Firefox and a Proxy application running then the connection flow would be as following.
Firefox → connects to 127.0.0.1 port ‘proxy’ → Proxy connects to ‘Internet’ → Leak
Interesting test and quite a disappointing performance from CIS, Chrome, firefox and IE. I do, however, give all credit to Opera for the way it handled this, very smart :-TU
The only way to ‘contain’ the browsers, other than Opera, is to add an explicit rule that prevents outbound TCP connections for loopback, which could be a problem for firefox and chrome, as they both use loopback for internal communication, firefox more so than chrome.
As a test, I ran the leak against Outpost firewall and Online Armor free and both applications produced alerts when selecting ‘Begin Test’ (images) unfortunately, I didn’t receive anything from CIS.
@Ronny - I don’t think this is the ‘classic’ 127.0.0.1 proxy leak, the alert from Outpost and the subsequent rule, if allowed, is for inbound connections on TCP port 80 to 127.0.0.1. This can also be seen in the Opera image.
What do you mean under have a strict configuration for this?
Anyway, Ronny, it is an issue not for you personally, but for the majority of users. For example, I myself use these browsers and don’t do any special settings for them for control OUT connections to loopback zone. I simply didn’t think about this till this day. I think almost all users do the same.
Yes, and browsers by default have the rule for OUT connections to loopback zone. This rule is in the predefined policy “Web-browser”.
No. Only browser connects to the Internet. You can do:
3) Application Rule for CDFIRLZ-Leaktest.exe: Block all IN and Out connections.
And what users did answer “No” the pool question? It is very interesting! Who are you?
Please post screenshots here where we can see that Comodo and (IE or Chrome or Firefox) have passed the test with default configuration “Firewall Security”.
Opera is safe for this leak. Yes. And it’s worth saying that with default settings.
How do you think, will developers of Comodo Firewall and CIS pay attention to this and will close a hole for the leak?
Maybe this is even a BUG, because as I have already said “Enable alerts for loopback requests” is marked in the Firewall settings.
I think about posting to Microsoft, Google and Mozilla about this issue :).
Other HIPS and Firewalls - other results! But I have interest only in Comodo Firewall because I use it now!
Yes. There is no talk about any proxy connecntions.
But for this leak it doesn’t matter to what port and by what socket(UDP,TCP ot other) connect. It can be any port and Protocol because you can see in the predefined policy named “Web-browser” a rule: Allow all IP Out From Mac Any To In[Loopback Zone] Where Protocol Is Any.
Comodo Firewall (5.9.219863.2196) don’t filter incoming requests to loopback zone at all! Neither by global rules nor by application rules.
Usually loopback packets are routed back by protocol driver itself and don’t reach NDIS infrastructure, where firewall minifilter resides, so they can’t be captured or filtered by it. I’m not sure for now (will investigate later), but it’s possible that OA or OP alerts socket creation, but not packets transition/delivery (CIS can do the same in “Proactive security” mode or simply when access to afd helper driver, “\Device\AFD”, is monitored).
My Comodo Firewall was configured with “Firewall configuration” by default. This is why it has failed the test. If we choose configuration “Proactive Security” then we can see an additional control of socket creation:
This means that no any program can create listening socket without alerts from Comodo. Comodo with configuration “Proactive Security” still protect us! But I think this option must be also added into “Firewall configuration” by default.
p.s. special thanks to ntoskrnl, he has promted me about these subtleties.
OS is Windows 7 x86 Ultimate and firefox 10b4, It just happened to be installed on the PC I was using for testing. I turned off the eyecandy as it’s a low spec PC. My son commandeered my rack for a LAN party.
Opera is safe for this leak. Yes. And it's worth saying that with default settings.
I think this is probably something to do with Opera Unite.
It seems that Comodo doesn't show alerts when Source IP is 0.0.0.0 and Destination IP is 127.0.0.1
I think that’s a good observation.
Usually loopback packets are routed back by protocol driver itself and don't reach NDIS infrastructure, where firewall minifilter resides, so they can't be captured or filtered by it. I'm not sure for now (will investigate later), but it's possible that OA or OP alerts socket creation, but not packets transition/delivery
Quite likely, it is something I’ll try and take a look at later today.
(CIS can do the same in "Proactive security" mode or simply when access to afd helper driver, "\Device\AFD", is monitored).
The subject of whether proactive security should be the default has been raised many times in the past, but nothing has changed…
What are you referring to when you say ‘trusted’? if you’re thinking about Network Zones, just because there’s an entry for a network, doesn’t make it trusted. The zone has to be made part of a rule, either application or global, to have any effect. You can see this if you look at the pre-defined browser rule.
Radaghast,
Did you investigate the work of the IP-TV player?
It seems to me there is present a similar problem. Typically, IP-TV player receives UDP connection on 0.0.0.0 and port 1234, but Comodo doesn’t show alert for this inbound connection. Also this connection does not present in Active connections monitor of Comodo.
Is this from your ISP or from the Internet? I don’t see this with IP-TV from my ISP.
Thinking about this, something like IP-TV typically uses a multicast and as far as I know 0.0.0.0 is a valid source address for both multicasts and broadcasts, when the *cast is for ‘this network’ Think also about DHCP. When a client doesn’t have an IP address it’s source address is 0.0.0.0. As far as I can recall CIS:
alerts and logs on outbound requests with a source address of 0.0.0.0 (doesn’t show in the alert)
logs but doesn’t alert on inbound requests with a source address of 0.0.0.0.
The problem is still present for default configuration Firewall Security and Internet Security.
For this configuration there is no control of listening sockets, no control of \Device\Afd\Endpoint. I don’t think that ALL users have CIS wich has default configuration Proactive Security, many users have Comodo Firewall with default configuration Firewall Security. That’s why developers of Comodo must think about adding in Protected Files and Folders group Sockets for control \Device\Afd\Endpoint and \Device\Nsi for configurations “Firewall Security” and “Proactive Security”.
Second question which is still present. Even with configuration Proactive Security Comodo still: don’t filter incoming requests to loopback zone at all, neither by global rules nor by application rules.
These connections not loged(so because they don’t filtered) even if we turn on checkbox “Enable alerts for loopback requests”(as I have already said). It means that any program if it once has got an allowed rule for access to \Device\Afd\Endpoint in Defense+ could listen any sockets(TCP UDP) on any ports for loopback addresses(127.0.0.1). For example you have an application that asked you about listening port 32768 and you allowed this. But from this time this application can listen for example 127.0.0.1:80 or 127.0.0.1:8080 without any alerts from Comodo(with “Proactive Security” configuration). This is also maybe dangerous in some cases!
Why this happens? It is also a very interesting technical question for me. And I would want to hear answers to it. It would be very nice if some of Comodo’s developers will say something about this here…
p.s. It is also interesting would Comodo protect if application will work with network card directly? Amd.sys will not used.
But I have interest only in Comodo Firewall because I use it now!