ZA PRO 4.5.530 against CopyCat leaktest

[gkweb]

--------------------
yes = passed
no = failed
--------------------

Hi there,

for those who don't know i'm the author of www.firewallleaktester.fr.st which is now firewallleaktester.webhop.net (since today ;) )
I asked my question on DSL report forum but don't have many answers.
As i said there, i'm not here to discuss of my website, some doesn't like it, others like it.

I'm updating my leaktest against firewall results currently, and of course when results are quite simple, i just add "failed" or "passed".

But this time i have a problem to say if Zone Alarm Pro passes Copycat or not.
Indeed, at highest settings, ZA failed it.
But, if i enable the "OpenProcess" API detection feature, ZA said me that copycat.exe try to "openprocess" iexplore.exe
At this time, no clue if it's a software hijacking or not, it could be legitimate, and no clue if it's for a network use or not.

So does really the "outbound software filtering" detected copycat ?

It's more like an application monitoring which detect that an executable is accessing an other one (like System Safety Monitor), which isn't that i'm testing.


I discussed of that with other people, and the important point seems to be that if there are no way to detect copycat when it does his internet access throught his hijacked software, then, and only then to catch earlier such exploit with "application monitoring feature like" would be the only solution, and so could be seen as a part of the outbound software filtering.

I want to show real results, and in front of such dilema i want to be as fair as possible with every firewall i'm testing, it's the first time i can't decide by myself, this is why i'm requesting your opinion on the subject.

Thanks in advance for your input.

regards,

gkweb.

[mvdu]

In my experience, it recognizes Copycat and doesn't let it run, so I certainly think it passes.

[gkweb]

i hope it doesn't "recognize" copycat leaktest in itself, it would be unfair ;)

but i understood what you mean, and no, ZA network application filtering doesn't see it, as it is also the case for all other firewall.

A feature of ZA enable you to see when a process try to gain access on another process, legitimaly or not, for internet connection or not.
This feature is a part of another kind of protection different than the network application filtering, it's application monitoring, exactly like System Safety Monitor does (but at a more basic level).
So ZA provides you features to increase your security and let you choose what to do, but they are nothing to see with application filtering at network level.

As you can see i discussed about it more with friends since last time, and i have my opinion.
If i would do leaktest with such feature, i would have to do the same for Kerio wich also has incorporated application monitoring feature, and to be fair, i should run SSM with other firewall which doesn't have such feature... But remember i only test on my website outbound software filtering (at network level).

I have finnished to write a page to explain this, normally you could only be able to click on it to read it when the next results will be published, but if you feel to need more information i can copy/past here the text.

At the end, if you disagree, it isn't a big problem, leaktests are available on my site and you can test them all on your system :)
The worst thing than can happen is that you badly understand results meanning, passing ALL the leaktest is possible without pb with a great software security suite, it's like people who are proud to block leaktest with SSM ;D

But i'm sure it's not your case ;)

[mvdu]

Well, I followed it like you want, and I believe you should count the extra feature. ZA recognizes and stops the test - that's what matters to me. I highly disagree with you, but it's your site..

[gkweb]

i understand you, but just consider that point :

you download something you think it's a game (ok may be not you, whatever) then you launch it.
It tries to "launch" or "access" an other process, you trust it, after all, it's a game ? So you allow it.

But in fact it's a trojan that now try throught his hijacked process to access the Internet, the network application filtering is your last shield !
(so application monitoring != network application filtering)

do you see the point i'm trying to explain?

And last point, it's not because "its my site" that i do what i want, i'm trying to be as fair as possible, which new firewall feature makes more difficult than never.


-{ Quote: "ZA recognizes and stops the test - that's what matters to me" }-

That's not what matters for my site, since i'm evaluating "outbound software filtering at network level", not application monitoring like SSM.
leaktests are "proof of concept", they demonstrate an "idea".

Copycat proof of concept is to use an existing thread within the process, to modify it (not to create one and to add it) and to access the Internet throught it.
To pass a leaktest, you have to win against his proof of concept.
What does ZA ? it blocks the "OpenProcess" API call when Copycat try to access a process, that's all.
Is doing an "OpenProcess" is the concept of Copycat ? no.

So ZA doesn't win at network level against the concept of copycat, it just block an executable accessing another one (even if not for an internet access, OpenProcess != internet acess).
ZA blocks Copycat ? well, fine, what if a trojan find a way to not use the Open Process API or at least to not be seen while doing this ? It will go trought your firewall which can't see and block it with his network application filtering, the proof of concept is still the same, it's still Copycat, but sudently ZA failed it...



So, to sume up my two ideas that i explained here : that you mistakenly allowed an malicious executable to access another one (no concept of network at this earlier stage) or that this malicious executable find a way to access another process without to be seen, your only chance is that your network software filtering can see it and block it, that isn't the case for ZA.

i quote again your sentence since it's often said :
-{ Quote: "ZA recognizes and stops the test - that's what matters to me" }-

ZA recognize an "OpenProcess" API call, nothing more.

What is an API call for you ? is it necessarely illegitimate? is it always for internet acess?
When ZA tell you that, you can't know if it's legitimate or not, you can't know if it's for internet access or not, and if you take the wrong decision (because you don't know it will be a malicious internet acess) you will have problems.

Last argue for this post : i create a firewall, i include application monitoring feature that _just_ check the launch of any executable (once allowed they can do that they want), like SSM would do.
So if i understood you rightly, this firewall would pass ALL leaktests because it can prevent them simply to launch ?
(so we don't care of network application filtering ??? )



At the end, unlike you seems to think, i'm not against to believe the contrary if you can convince me, i just provide you my argues, and as of now i'm not convinced of the contrary.

[Phant0m]

The "OpenProcess" API process is much too early to actually definite it’ll be using Client Environments, and is something sandbox would support. That cannot be defined a part of Application Filtering Layer.

If he gives Pass status for that type of exploit, then his entire site is impropriate and misleading, Entire Re-write needs to be done.

gkweb I’m curious if you renamed copycat and packed it and executed it, does ZoneAlarm still pick it up? Hmmm :)

[gkweb]

i think it will, since in fact ZA seems to have put a hook on OpenProcess API call.
(But i will do the test just in case)

[Phant0m]

Possible... :)

[mvdu]

I plan on using common sense when it comes to trusting apps. For what I want, ZAPro does the job with Copycat. I am satisfied.

Your site says NPF doesn't pass PCAudit, yet I can deny access and there's no leak. Now in this case, it didn't recognize the app., but Outpost also doesn't recognize it, yet it's listed as passing it. This is why I always do my own testing from your links.

[gkweb]

i understand your point of view, but i'm not sure you read my post 2 post above.

ZA block a process access, but Copycat isn't a process access, it's a proof of concept and ZA didn't deal with the idea that Copycat wants to demonstrate, it just prevent it to run in fact.

I know ZA make you able to pass Copycat, but does his outbound application filtering passes Copycat ?
(which i am evaluating on my site).

All the problem is here.

The feature involved to pass Copycat isn't a matter of "firewalling", but application monitoring.

-{ Quote: "
Your site says NPF doesn't pass PCAudit, yet I can deny access and there's no leak. Now in this case, it didn't recognize the app., but Outpost also doesn't recognize it, yet it's listed as passing it. This is why I always do my own testing from your links.
" }-

this for what mainly the site is make, for make you able to test yourself.
(BTW, if you obtain such result, pls send me a screenshot at gkweb@wanadoo.fr of the popup with details shown.)

pls stay focus on ZA or at least on the problem about "application monitoring" against "outbound applicating filtering" (network layer) ;)

[mvdu]

I made RealPlayer a trusted app., and now it might be allowing it OpenProcess calls. I see what you mean. Maybe you should leave it as failing for your purposes, but I find it more useful if the overall picture is given.

I want to stay on ZAP, but that had been on my mind for a while and I wanted to bring it to your attention. :)

[gkweb]

You had given a good example too with RealPlayer.

The same problem with ZA exists also with Kerio.
Kerio failed WallBreaker, if you activate only his menu tab "Network Security".
But if you activate his "System Security", another menu, then it behaves like SSM and blocks WB trying to access IE, not because it's an internet access, just because it's an acess.

Like you mentioned it, there is a difference between outbound software filtering strenght, and overall firewall strenght, depending of the point of view, a result could be failed or passed.

Since i always evaluated outbound software filtering at network layer (which is that leaktests asks me), i will probably count it failed, and i will add a link on the result page talking about this problem, and will say that results are different than the overall firewall feature could have, indeed, firewalls could have extra features to overcome their outbound software filtering vulnerabilities (that is the case at least for ZA and Kerio).

In fact, this thread will help me to write a better "results details/explanation" page :)
(until someone convince me of the contrary)

At the end, as i said, the most important purpose of my site is to help users, that they can do themselves leak tests, the results page is just a quick overview of vulnerabilities at network layer, you shouldn't take it as a Bible (i don't know if it's the right word, i mean the holy book).


If you have another input to add, or anything else, i'm still open :)

[mvdu]

Yes, I think that's a good idea - put an asterisk next to ZA Pro, and then say it can pass copycat if the program is not given access.

[gkweb]

in my current tests page ( on my comp ), i added a new column "AM" with an icon "+" for firewall which has AM (Application Monitoring) and an icon "-" for those which doesn't have.

This icon is explained, and in the "results details/explained" page i explain that such AM feature overcome outbound software filtering vulnerabilities and allow you to pass more leaktests.
(ZA and Kerio are concerned).

I think that way, both information are available :)

[mvdu]

Sounds good - I'm satisfied now. Look into that other thing I told you about , too. ;)

[gkweb]

If someone else has any other suggestion about how to deal with "application monitoring" against "outbound software filtering" (and what results should counts), feel free to give your input here, even if i think that with mvdu and Phant0m we found what we were looking for :

"application monitoring" different than "outbound software filtering".

You can agree too, not necessarely disagree ;)

[jvmorris]

gkweb,

Okay, you're now being confronted with an issue that I thought would eventually come up (even in the context of the leaktests on which you concentrate).


The personal software firewalls (PSFs), in particular are evolving (and not always in a straight-forward fashion).

Just for purposes of exposition, let's start with a far older set of examples with which many posters here may be familiar.

At one point, the end-user could select between whether closed ports could be reported as 'closed' or 'stealthed'. (A user-selectable option, at least for a short time.) Then, we started getting to PSFs that automatically stealthed these ports and the user had no choice whatsoever. And, of course, today I'm not personally aware of any PSFs that still gives the end-user the option; it seems they all get stealthed, whether the end-user would choose to do this or not.

At another point, PSFs started doing 'file authentication' (well, at least on the main executables and with differing levels of comprehensiveness). Most used (and still do) MD5 authentication; others used SHA1 authentication. Today (and finally after almost three years of incessant bitching -- at least on my part ;) ), some of the PSFs are starting to do a bit more comprehensive file authentication, including on root processes, DLLs, etc. But still, sometimes this is by default (and it may not even be possible for the end-user to change the default) and sometimes as a configuration option offered to the end-user.

Now, I know that neither of the above is really the focus of your leaktest results on your website, but -- still -- let's consider what would happen if it were and you hit on the transition period.

You'd confront three (or four) options and have exactly the same problem you confront here: Some of the PSFs would not provide this feature at all. Some of these PSFs would have this an an embedded 'feature' which the end-user could not modify at all. Some of these firewalls would have this as a user-selectable "on/off" , i.e., "enabled/disabled" feature, (possibly with different 'default' settings) and Some of these PSFs would go a bit further and provide a capability for the end-user to further configure these options.

Now, the problem that you've always faced (even in the very limited set of comparative evaluations you are trying to provide) is how would you equitably compare these features? As I hope you see (and think you are beginning to realize) this is not at all an easy question to answer. If anything, it's further complicated by the PSF vendors offering a spectrum of PSFs (and usually having multiple releases to support) on various OSs (and sometimes the PSF that might get installed on, say, Win XP is considerably different from what might get installed on Win 98).

And you are confronted with precisely the same issues involving leaktests on (various releases of) the various PSFs on various OSs.

I don't have a simple answer for you in this instance. Some of the PSF vendors are 'embedding' the solution to various leaktests in the code of their most recent releases. Others are leaving it as an 'option' (and not necessarily a well-specified one, in my estimation). Furthermore, where the 'option' exists, it may (or may not) be configurable to some extent. I don't know what to tell you in this instance, but I think it's a subject that is worthy of more exploration and I hope to see more discussion of this from others.

A lot of the PSFs are now turning into "security suites", as was recently discussed on the DSLR Security Forum. Sometimes, the 'feature' relevant to a particular leaktest vulnerability is innate to the package; other times it's hidden away in the 'extensions' involved with the "suite". (Indeed, I think you ran into this a long time before you got around to the Copycat/ZAP issue.)

I think it's time to stand back and take a bit more comprehensive look at precisely how you need to address these kinds of issues.

[gkweb]

The problems i am now facing was well described by you :)

This is why i'm still trying to stay on the network outbound application filtering to respect leaktests ideas, but now more than ever, new firewall features make my tests criteria more difficult to define.

This is why i like to say that after all, my results are just a quick overall of firewall vulnerabilities (all are tested fairly with same criteria) and that the main site purpose is to make you able to test by yourself following your own criteria.

Yes i take in count firewall evolution, this is why i will modify the leaktest page results (in addition to update results), and this si why testing criteria will be explained more than it be actually on the site, the main idea is, as said above, that leaktests are proff of concept, ideas, and blocking their execution is not passing the idea.

I will add just as an example, Look'n'Stop 2.04p2 with lastest driver blocks with his outbound application filtering (network layer) the leaktest "Thermite". So i think there is no reason to count "unfair" feature like application monitoring (which is the easy way) until leaktests becomes so much sophisticated that application monitoring will be the only solution.
When this time will come, firewall no more will win against leaktests "ideas", so i will have to remove the results page, but we aren't there as of now ;)

For me, for now, Application Monitoring has nothing to do with "firewall".
Vendors can add it, but it still different than outbound software filtering that leaktests bypass (leaktest was never meant to bypass application monitoring).

regards,

gkweb.

[gkweb]

From "Morgott" on another thread:
--------------------------------------------

gkweb said :
-{ Quote: "
What you said about outbound protection is partially true only.

Read my other post titled "ZA 4.5 against copycat leaktest", all is said on it
" }-


O, but I already read it, hehe

The point is, open process protection is a necessary layer in the defense against trojans that hijack other apps by directly inject themselves in these (open) apps instead of just calling them. Now upon running Copycat, which (unlike Thermite) allows U to choose the target process, there are 2 possibilities:

1) The target app is NOT allowed access to internet. Take notepad, for example. In that case, firewall will intervene both on open-process protection AND app-filtering levels: first, it will ask U if you wish Copycat to access Notepad.
If you answer 'No', then the test stops there.
But if you answer 'Yes', then notepad will be "patched in memory" and thus turned into an app which can now access the Net. But then firewall will step in again, ASKING YOU IF YOU WISH TO LET NOTEPAD ACCESS INTERNET, to which you can still answer 'No'. This is an example of "double-shielding" at work (sorry for the expression, couldn't help it I'm a Trekkie ): first open-process protection, then application filtering. So in this case, the test is passed.

2) Now there's the controversial & most interesting part - the target app IS allowed internet access, take Iexplore for example. Again, ZA will step in to complain about copycat trying to access the browser. Once again, answering 'No' closes the case.
But if the user answers 'Yes', then indeed Copycat will access the Net (or rather, the modified "Iexplore/Copycat hybrid" will). BUT ISN'T THAT NORMAL? After all, as I said the browser IS allowed internet access! The fact that it was modified in memory is a process protection issue only, and has nothing to do with 'application filtering' since the user chose to give the browser application Net access, and also explicitly allowed Copycat to modify the open browser process!!
So seen in this light, the firewall again passes the test..

Sure, as U said in the other thread, some trusted applications can be required to (and must be allowed to) use other internet-accessing apps to connect to the Net. But then again, there is a difference between a program calling another app such as Iexplore and making it access the Net, and a program that injects itself directly into another app, ie. Iexplore, and thus modifies it, rather than simply call iexplore. Take explorer.exe, 4 example: it must be granted the right to use (call) other programs to access the Net (otherwise apps such as P2P, ... won't be able to connect to the Net). BUT WHAT KIND OF TRUSTED PROGRAM WOULD HAVE THE NEED TO INJECT ITSELF INTO ANOTHER?
A program that tries to patch another trusted program instead of just calling it can only be a trojan, and thus denotes malicious intent (someone correct me if I'm wrong ).

BUT even then: suppose a program does require such "open process" privileges, in addition to having the right to use other apps to access the net. Suppose this prog is called 'Good.exe'. Now good.exe can call, for example, Iexplore, AS WELL AS patch it by injecting itself into it. OK. So? No problem! Recent firewalls (not only ZA) all have application & component control using MD5 signature authentification. Thus if the 'Good.exe' file is modified, then the firewall will pop in to advise the user that a MODIFED version of Good.exe is either trying to use Iexplore to access the Net, or trying to inject itself into Iexplore, depending on the context. In both cases, the system remains protected, and the shields hold (oops I did it again ).

So there U go comrade, that's my take on the situation. Application filtering (by its very definition) and application/component authentification are NOT enough to avert threats such as self-injecting hijacking. Open process protection is the necessary "third layer" to complete the protection, and ZA seems to have taken the first step. Other firewalls such as LnS and Outpost will have no choice but to implement it if they are to protect against these techniques.

Nevertheless, I must admit that your thread got me thinking 4 some time...

BTW, I checked about a leak test being possibly blacklisted by ZA (a dirty trick that the makers of BlackIce have already carried out in the past, cf. the grc.com 'Shields Up' site - shame on 'em!). So I renamed Copycat.exe, changed it modification date and even altered its content by changing some text within using a hex editor, thus changing its MD5 signature. ZA still passed the test...

Besides, I've so far tried about 5 different firewalls. Though ZA may be my favorite for the moment because of its new features, CPU load still is an important criterion that Zonelabs (and others) doesn't seem to have really dealt with up 2 now.
Zonealarm wallops a load of RAM over time, who knows why (from 7 Mb at startup, 'vsmon' bloats up to over 30Mb).
LnS seems to have the edge in that matter - it uses few resources, from what I've read. On the other hand, Both LnS and Outpost fail some AWFT tests, unless Explorer is given certain restrictions... LnS is also difficult to configure and sometimes leaves port 135 open by default!!!

Man, why does every software have to have its flaws? Can't someone just design a firewall that comprises the benefits of all the other firewalls WITHOUT their drawbacks???

From "Morgott" on another thread:

[gkweb]

@Morgott

-{ Quote: "
2) Now there's the controversial & most interesting part - the target app IS allowed internet access, take Iexplore for example. Again, ZA will step in to complain about copycat trying to access the browser. Once again, answering 'No' closes the case.
But if the user answers 'Yes', then indeed Copycat will access the Net (or rather, the modified "Iexplore/Copycat hybrid" will). BUT ISN'T THAT NORMAL? After all, as I said the browser IS allowed internet access!
" }-

I think (no offense!) you didn't fully understand how leaktests concept works.

The most understandable is an example :)
The target process is fully trusted and has full access over the internet (let's say IE).
We allow the malicious executable (without knowing it is malicious) to access IE, and at this point you said that the hijacked software couldn't be blocked, which si wrong.
Indeed, let's take "Thermite" leaktest, it first do an "OpenProcess" before injecting thread and hijacking the browser.
With any application monitoring software/feature, you allow it to access IE, and even with this, Look'n'Stop block his internet access when it wants to access the internet.
So the bypass of the first shield (application monitoring) doesn't mean at all that the second shield is necessarely bypassed too.

A more simple example may be is Tooleaky that many firewall blocks, first shield is passed, and even with IE having full access Tooleaky is blocked.


-{ Quote: "
Sure, as U said in the other thread, some trusted applications can be required to (and must be allowed to) use other internet-accessing apps to connect to the Net. But then again, there is a difference between a program calling another app such as Iexplore and making it access the Net, and a program that injects itself directly into another app, ie. Iexplore, and thus modifies it, rather than simply call iexplore. Take explorer.exe, 4 example: it must be granted the right to use (call) other programs to access the Net (otherwise apps such as P2P, ... won't be able to connect to the Net). BUT WHAT KIND OF TRUSTED PROGRAM WOULD HAVE THE NEED TO INJECT ITSELF INTO ANOTHER?
" }-

It could be legitimate.
So far, i can tell you that XP services need to WRITE into another processes, there is "lsass.exe", "svchost.exe", many software (i know norton doing it).
For example, System Safety Monitor does DLL injection into running processes, Process Guard "Close message handling" feature inject threads into processes if i remember right, i know few port to process mappers are doing DLL injection/thread injection and code modification, and so more...
You would be surprised to see how many AV/AT/FW software accessing and modifying other processes.

-{ Quote: "
So there U go comrade, that's my take on the situation. Application filtering (by its very definition) and application/component authentification are NOT enough to avert threats such as self-injecting hijacking. Open process protection is the necessary "third layer" to complete the protection, and ZA seems to have taken the first step. Other firewalls such as LnS and Outpost will have no choice but to implement it if they are to protect against these techniques.
" }-

I never said current firewall can, or ever will be able to handle all by themselves, i just notice outbound software filtering vulnerabilities (at network layer), and yes, i totally agree that additional layers of securitty are really _needed_ to handle all trojans/leaktest, if you take a look at my site, you will see it in the "advices" page, and "software" page, we totally agree on this point ;)

That i'm trying to say, is that i'm only testing one firewall feature, application monitoring is another feature which could _should_ (to my eyes) be handled by dedicated software, and as i answer to the excellent
points from JV Morris, leaktest was never meant to bypass application monitoring, so of course, if you use such feature you will pass everything...

interisting subject, isn't it ? :)

[Morgoth]

-{ Quote: "I think (no offense!) you didn't fully understand how leaktests concept works.

The most understandable is an example
The target process is fully trusted and has full access over the internet (let's say IE).
We allow the malicious executable (without knowing it is malicious) to access IE, and at this point you said that the hijacked software couldn't be blocked, which si wrong.
Indeed, let's take "Thermite" leaktest, it first do an "OpenProcess" before injecting thread and hijacking the browser.
With any application monitoring software/feature, you allow it to access IE, and even with this, Look'n'Stop block his internet access when it wants to access the internet.
So the bypass of the first shield (application monitoring) doesn't mean at all that the second shield is necessarely bypassed too." }-

Bah, first of all, no offence at all, comrade - I'm more or less new to this stuff (closer to 'new' in fact). All Jedis were apprentices some time ;D

But then again, I fear I didn't quite understand your example.

First of all, when U say 'Application Monitoring', I suppose U mean 'Process Protection', right?
I also gather that U used the beta version 2 of LnS 4 - which is supposed to block Thermite, still right?

Second, how can LnS possibly block IE (Iexplorer) only when it is being hijacked by Thermite WITHOUT being able to handle thread injection? That seems contradictory indeed, for that would mean that
1) It does not know that IE has been modified in RAM (since it has no process protection)
2) Yet it DOES know that IE has been modified in RAM since it blocks it only when Thermite hijacks it !?!! How can it do that without protecting (monitoring) IE ?

Third, another detail irks me: have U tried LnS 4 beta 2 against Copycat by choosing IE as the target process (as for thermite)? From what I've heard, it fails at on that test ... even though it passes the Thermite test, when BOTH leak tests try to hijack the SAME target (IE) in the SAME manner !?!!

I'm not stating anything for sure, but if I may suggest a possible explanation to this result:

The beta 2 patch for LnS 4 has been specifically tailored to the Thermite test (perhaps an MD5 signature recognition - try modifying Thermite with a Hexeditor ;)). In a way, that could be considered "cheating"! Sounds far-fetched, but it's the only explanation I can think of as to why LnS4b2 blocks Thermite, and yet not Copycat on IE...

A most interesting topic indeed. Awaiting feedback...

[gkweb]

-{ Quote: "
First of all, when U say 'Application Monitoring', I suppose U mean 'Process Protection', right?
" }-

I mean all methods involved to control/allow/block from the simply _launch_ of any executable to most adavanced process _access_ (DLL injection, thread injection, process memory modification request), all that is a request to the OS from an executable that can be hooked.
A full Application Monitoring software, for understand what i mean, is System Safety Monitor.
If you take the OSI model, application monitoring occurs on the 3 higher layer (session, presentation, application), whereas outbound software filtering occurs on the 3 layer before (link, network, transport)
Sorry if i badly translate my french knowing layer name of the OSI model ;)




-{ Quote: "
Second, how can LnS possibly block IE (Iexplorer) only when it is being hijacked by Thermite WITHOUT being able to handle thread injection? That seems contradictory
" }-

I tested LnS 2.04 last beta version and last beta driver.
Indeed, any firewall blocking fairly leaktest at network layer HAD to collect
information on the application layer to be able to make the link between the internet access and the requesting executable.
But there is a difference between :
- controling thread injection ( that could be legitimate ) and alert the user when and only when the injected thread attempts an internet acess
- controlling thread injection and alert the user when any is done (earlier than the other).

So there is a difference between colecting information about API in use and process access to be able when the time will come to show the guilty, and to base all the firewall on it to turn it in an application monitoring software without taking care of false positive.

This, which is legitimate to increase his security (so i understand vendors), isn't valuable for my testing purpose which only focus on the filtering at network layer (see the OSI model).

-{ Quote: "
Third, another detail irks me: have U tried LnS 4 beta 2 against Copycat by choosing IE as the target process (as for thermite)? From what I've heard, it fails at on that test ... even though it passes the Thermite test, when BOTH leak tests try to hijack the SAME target (IE) in the SAME manner !?!!
" }-

ALL firewall that i evaluated fails Copycat.
As of now, all outbound filtering that i evaluated failed it, so the only way to block such "executable" is application monitoring (the leaktest concept is still not blocked so not "passed", but at least you have tools/feature to prevent such concept to run on your system).

Not the two leaktest hijacks the same software in the same manner.
Copycat can hijacked any browser or any software, it let you choose the PID number to hijack when you run it, but to simplify we will say both leaktest targets IE.
Thermite injects a thread into the process (it creates a new one) whereas Copycat use and modify an _existing_ thread into the process, this is why
it is so much difficult to block.

-{ Quote: "
The beta 2 patch for LnS 4 has been specifically tailored to the Thermite test (perhaps an MD5 signature recognition - try modifying Thermite with a Hexeditor ). In a way, that could be considered "cheating"! Sounds far-fetched, but it's the only explanation I can think of as to why LnS4b2 blocks Thermite, and yet not Copycat on IE...
" }-

LnS doesn't use such dirty trick.
In fact you already have a part of the answer with my answer just before (Thermite different than Copoycat).
I tried with renamming it in "toto.exe" and in packing it with UPX and it still detect it.
I don't think ANY firewall vendors will take such risk (like BlackIce does...) because if i discover such dishonessty, i will put a bullet on this firewall and everyone will know the firewall company policy : to lie to his customers providing them a false sense of security.


ouch, my hands hurt me and my keyboard is smoking, call fire men ! ;)

[Morgoth]

Ok thanks 4 the explanation comrade

That was exhaustive enough. U must be a Jedi Computer Master or something ;D. I wish I knew where I could QUICKLY learn how to program such stuff...

So if I understand correctly, LnS 4 beta 2 CAN handle thread injection but not thread modification

And it is also capable of telling WHAT the injected thread is trying to do (ie. net access)? Impressive...

In other words, ZA needs a little more fine-tuning to be able to do the same thing since for the moment it only acts at a "lower OSI level" - correct me if I'm wrong.

As soon as it can handle Copycat-style trojans too in a similar fashion, I'll switch to this firewall. I hope others will follow in soon enough.

2 more questions:
- when ZA blocks a thread injection/modification, at which OSI level does it intervene?
- When LnS4b2 blocks a thread injection AND sees that the new thread is trying to access the Net, at what OSI level does step in??

[gkweb]

No, i'm still a Padawan but may be a day the force will be with me and i'll become a Jeidai ;)

About LnS, and in fact generally, to add a thread is easier to see (like to add a DLL).
Modifying which already exists is more stealth (and a lot harder to detect), this is why just hooking "OpenProcess" API call prevent any further leaks (since whatever you want to do on a process you must open it first).

Still generally, i don't think it's impressive, i think you have to do brainstorm training, and when you find the "trick" that no one thought you have winned.
Windows process interaction is a wide subject, and each month new technique of attack/protection is discovered.
It's all about Hacking (in the right term, not cracking) :)

About Application monitoring (and so ZA which have a feature like this), it takes place in higher layer of OSI model (not lower) than all which is about network.

7 - Application
6 - Presentation
5 - Session

4 - Transport

3 - Network
2 - Link
1 - Physics

Application Monitoring -> 5,6,7
OUtbound filtering -> 2,3,4

AM prevents leaktests to reach lower layers.

-{ Quote: "
- when ZA blocks a thread injection/modification, at which OSI level does it intervene?
" }-

I think it's at "Application Layer" (7).

-{ Quote: "
When LnS4b2 blocks a thread injection AND sees that the new thread is trying to access the Net, at what OSI level does step in??
" }-

I don't know LnS code, i don't know which method authors uses, but if i have to bet :
first step : layer 7 (doesn't alert at this stage, just let an eye on it)
second step : when a "request" to go to lower layer is done, it's block it and popup the user (layers 5,6,7), before it reachs the layer 4.

It's different to block a request to launch or open a process (request toward layer 7) than to block IE to access an URL (request of layer 4,3,2).
It's the big difference for me between application monitoring and "Firewalling".

If we go other the leaktests topic, a multi layered security is stronger than to bet that you will prevent any threat to go outside of layer you are monitoring, if you fail it, other software will receive and handle it.
Just imagine a football match !
The goal man is the application monitoring, the web behind him is the outbound software filtering, and again behind, it's the Internet.
If one fail, the other can catch the threat.
But if the threat cheats and is very "small" (for the metaphore) it will may be pass trought both the goal man and the web behind it to reach the internet, so you need to further enhanced your security by adding more security layer ;)

[jvmorris]

gkweb,

I'm not sure who actually said this (you or Morgott), but you've just broached another can of worms below . . . .
-{ Quote: " quoting: gkweb link=board=23;threadid=16981;start=15#msg106272 date=1070414155] . . . . Nevertheless, I must admit that your thread got me thinking 4 some time...

BTW, I checked about a leak test being possibly blacklisted by ZA (a dirty trick that the makers of BlackIce have already carried out in the past, . . . So I renamed Copycat.exe, changed it modification date and even altered its content by changing some text within using a hex editor, thus changing its MD5 signature. ZA still passed the test...
" }-

For the moment, let's forget about ZA, BID, and Gibson's Leaktest (1.0, I believe that was). If a firewall (from any vendor) passes a particular leaktest, are you actually then checking to ensure that it's not accomplishing this by this kind of subterfuge? Let's face it; it could be highly tempting for a PSF vendor to be the first one to 'pass' Copycat.

I hate to say it, but this can easily turn into a lot of additional work. For example, just renaming copycat.exe to msword.exe (in the file system and even possibly relocating it) isn't going to cut the mustard. Nor is changing the (file system) DateLastModified. Even changing the hash isn't necessarily definitive by modifying a text string within the file.

At a minimum, you'd also need to change the file header internals, and the original executable file name is usually found there, along with an internal FileDateLastModified field. You'd probably be best off to also add a nul byte to the end of the file. Now, these kinds of changes will certainly change the hash (whether CRC32, MD5, SHA1 or whatever the PSF uses).

See, here's the problem. If a PSF vendor was bound and determined to 'pass' some especially sensitive leaktest (presumably that no one else could easily pass and presumably by hard-coding in the PSF itself), they're going to check one helluva lot more than the file system's name for the file, the file system's date last modified, and the hash. Heck, we checked more than that with NIS FileCheck! And the latest versions of NIS/NPF can actually go out and check for additional information when such a file is first encountered. (At the moment -- as far as I know -- NIS simply checks to see if it can validate such a file, but there's absolutely nothing to prevent them from doing the same to invalidate a particularly pesky Leaktest, for that matter.) And, no, I don't believe that Symantec has done this.

But I hope you see the potential complication here for your analyses to be accurate.

[gkweb]

You are right, and i can only ensure of such dishonnest tricks aren't use against my leaktest only (i have totally different version on my comp).

Even, for other leaktest, change filename and pack them with UPX isn't enough as we can notice it from you said.

As i said i just hope that no firewall vendors is circumventing currently leaktests like that, because if we discover that... he will be face serious customers complains, it would be unacceptable.

[jvmorris]

-{ Quote: " quoting: gkweb link=board=23;threadid=16981;start=15#msg106531 date=1070482349]. . . . Even, for other leaktest, change filename and pack them with UPX isn't enough as we can notice it from you said.

As i said i just hope that no firewall vendors is circumventing currently leaktests like that, because if we discover that... he will be face serious customers complains, it would be unacceptable." }-

If you find one, you become the next Steve Gibson! ;D

[gkweb]

"gkweb Gibson", yea, sounds good :)

lol, let stay in the reality ;)

[Morgoth]

gkweb :

Thx again for the explanation :).
However, when U said:

-{ Quote: "this is why just hooking "OpenProcess" API call prevent any further leaks (since whatever you want to do on a process you must open it first)." }-

I fear I didn't quite catch on:
forgive my lack of knowledge (I'm not familiar with the meanings of the terms "Hook" or "API", though "hook" may have something to do with fishing? ;D), but whenever a trojan wants to inject itself into a process, isn't the process already open ??? (For example for Thermite or Copycat against IE, the user himself must open IE...)


Mr Morris :

-{ Quote: "[...] are you actually then checking to ensure that it's not accomplishing this by this kind of subterfuge?" }-

Affirmative, that's the theory I'm trying to corroborate/invalidate. Some have already done so. Others could be tempted, regardless of the possible consequences.

-{ Quote: "Even changing the hash isn't necessarily definitive by modifying a text string within the file.

At a minimum, you'd also need to change the file header internals, and the original executable file name is usually found there, along with an internal FileDateLastModified field. You'd probably be best off to also add a nul byte to the end of the file. Now, these kinds of changes will certainly change the hash (whether CRC32, MD5, SHA1 or whatever the PSF uses)." }-

I'm not sure if by your statements you meant that :
"Altering the test file's hash does NOT suffice to test a firewall's 'honesty' - further tests are needed"
or instead :
"The methods I used (changing some text bytes within the test file) are NOT enough to change a hash"

although I'd incline for the latter explanation. IF so, you may well be right - changing a few bytes could well leave the hash unchanged. But here's a counter-example: the eDonkey P2P app uses MD5 authentification to be able to pinpoint fake sources. So this I tested: I placed a 53 Mb .img CD image in my shared folder and noted the MD5 value that eDonkey returned. Then I altered just 1 byte, towards the beginning of the file, but nowhere near the header. Well, the new MD5 value was RADICALLY DIFFERENT!!!

Anyways, 'tis probably true, further tests might be needed. Perhaps changing the structure of the source code itself would do the trick...

I'll let U attend 2 it ... feel dozy now ... time 4 a 5 min. nap ... ;D

[jvmorris]

-{ Quote: " quoting: Morgoth link=board=23;threadid=16981;start=15#msg106640 date=1070502067]. . . . Mr Morris :

-{ Quote: "[...] are you actually then checking to ensure that it's not accomplishing this by this kind of subterfuge?" }-

Affirmative, that's the theory I'm trying to corroborate/invalidate. Some have already done so. Others could be tempted, regardless of the possible consequences." }-
-{ Quote: "" }-
I'm probably screwing up the quotes here, but you've raised a very critical issue in my estimation. As gkweb notes (and Gibson maintains), BID apparently did something like this in its response to Gibson's Leaktest 1.0. Gibson publicly stated (in his own forums) how he could defeat this (and he was quite correct, at that time).
-{ Quote: "-{ Quote: "Even changing the hash isn't necessarily definitive by modifying a text string within the file.

At a minimum, you'd also need to change the file header internals, and the original executable file name is usually found there, along with an internal FileDateLastModified field. You'd probably be best off to also add a nul byte to the end of the file. Now, these kinds of changes will certainly change the hash (whether CRC32, MD5, SHA1 or whatever the PSF uses)." }-

I'm not sure if by your statements you meant that :
"Altering the test file's hash does NOT suffice to test a firewall's 'honesty' - further tests are needed"
or instead :
"The methods I used (changing some text bytes within the test file) are NOT enough to change a hash"

although I'd incline for the latter explanation. IF so, you may well be right - changing a few bytes could well leave the hash unchanged. But here's a counter-example: the eDonkey P2P app uses MD5 authentification to be able to pinpoint fake sources. So this I tested: I placed a 53 Mb .img CD image in my shared folder and noted the MD5 value that eDonkey returned. Then I altered just 1 byte, towards the beginning of the file, but nowhere near the header. Well, the new MD5 value was RADICALLY DIFFERENT!!!

Anyways, 'tis probably true, further tests might be needed. Perhaps changing the structure of the source code itself would do the trick...
" }-

No, I think you've misunderstood the nature of my comment. If some PSF vendor was critically determined to pass a published leaktest, they'd check one helluva lot more than the MD5 or SHA1 hash (and they wouldn't even bother to check the directory filename or DateLastModified). As gkweb notes, changing all of these parameters is trivial, even for the most casual investigator. And they could then embed code in the PSF to shut down the leaktest.

Now, what we've been referring to as 'leaktests' in this thread are actually non-malicious demonstrations of potential vulnerabilities; they are not malicious apps (or exploits) by any means (as far as I know). Indeed, gkweb made this point in his response to mvdu. Consequently, shutting down a published "leaktest" (and only that) does not mean that the PSF is invulnerable to the vulnerability that the leaktest was intended to demonstrate. (Still with me, here?)

Well, the PSF vendors are quite aware of how to test any app to determine if it's a disguised leaktest. If one of these was worth their effort (Copycat, for example?) it would be all too easy for them to embed code to simply shut the "leaktest" down (in most instances). For that matter, if you were a PSF vendor, wouldn't you love to be the first vendor to show that your firewall solves that problem? The temptation is potentially overpowering. I'm simply asking whether gkweb is doing anything to detect such nefarious behavior on the part of the various PSF vendors. This is not to say that any of the PSF vendors will do this; it's simply intended to keep all of them honest -- for fear of disclosure, if nothing else.

[jvmorris]

Morgoth,

Sorry, missed a point below (and what's with all this Mr. Morris stuff that's starting to show up here? Why, I've even been known to respond to yomama! on occasion -- if I knew it was directed to me. :))
-{ Quote: " quoting: Morgoth link=board=23;threadid=16981;start=15#msg106640 date=1070502067]. . . .I'm not sure if by your statements you meant that :
"Altering the test file's hash does NOT suffice to test a firewall's 'honesty' - further tests are needed"
or instead :
"The methods I used (changing some text bytes within the test file) are NOT enough to change a hash"

although I'd incline for the latter explanation. IF so, you may well be right - changing a few bytes could well leave the hash unchanged. . . . ." }-
I meant the former, not the latter interpretation. Indeed, if you or gkweb changed a few bytes (or even added a few bytes to the file), the MD5 or SHA1 hash would almost invariably change -- and dramatically as you note. A Trojan writer, on the other hand, could modify the code without changing a CRC32 hash (that's almost trivial these days) or (with a bit more effort) the MD5 hash. Changing a SHA1 hash (or possibly something more exotic) is quite difficult however. Unfortunately, the ways this would be accomplished would undoubtedly change some other characteristic of the file -- and that's precisely why some PSF vendor would check far more than the hash signature (if they were intent on a bit of subterfuge). Now, this behavior would not be much better than being a blackhat, but it is certainly feasible.

[gkweb]

@Morgott

-{ Quote: "
gkweb :

Thx again for the explanation .
However, when U said:

Quote:
this is why just hooking "OpenProcess" API call prevent any further leaks (since whatever you want to do on a process you must open it first).

I fear I didn't quite catch on:
forgive my lack of knowledge (I'm not familiar with the meanings of the terms "Hook" or "API", though "hook" may have something to do with fishing? ), but whenever a trojan wants to inject itself into a process, isn't the process already open (For example for Thermite or Copycat against IE, the user himself must open IE...)
" }-

First, let me explain what a "hook" is (no, not fishing in my case ;) )
In Windows system, all program does call windows function all the time, this functions are known as API (Advanced Programming Interface).
So, if you are interested to see who and when is using a particular API (a critical one for what you are monitoring), you can put a "hook" on it, i mean a piece of code which will be the first to handle the particular API calls before it forward (or block) those to the API.
Thus you can control this API (allow/deny calls on it) or simply monitoring it (see which program access it).

Second, "open" IE hasn't the same mean than "open" a process.
When you "open" IE, in fact you start it, and then, the process is running.
A running processes is not opened to any other process.

When a process want to manipulate another one (suspend, resume, terminating, modifying, etc...) it must ask to the OS the authorization to access the process. To do that, it must use the "OpenProcess" API and say in which manner it wants to access the process (full control, read, write, etc...).
After that, the OS say "ok" and give to the requesting program a free "handle" of the target process (just a number), without this number you can't do anything.
"OpenProcess" mean "I want to acess this process with full permission, can I?".

In programming, it _very_ common to have to open something first to access it (registry, files, process, socket, etc...).

So, blocking an "OpenProcess" call is by far too much earlier in the leaktest stage, there is nothing malicious in itself (you can't know what will follow).

@all

About leaktest circumventing method, even changing the MD5 hash of the files, change file name, pack it with UPX, and then with ASPack.... isn't an evidence that the firewall isn't able to recognize it, what if it just read windows title ?

I can only ensure that a firewall will be honnest while passing successfully my leaktest (Wallbreaker) because i perfectly know it and have already _very_ different version.
So vendors be aware, do not cheat on my leaktest :)

[Morgoth]

-{ Quote: "Sorry, missed a point below (and what's with all this Mr. Morris stuff that's starting to show up here? Why, I've even been known to respond to yomama! on occasion -- if I knew it was directed to me. ) " }-

??? Heaven, ye moderators worketh in mysterious ways...

-{ Quote: "A Trojan writer, on the other hand, could modify the code without changing a CRC32 hash (that's almost trivial these days) or (with a bit more effort) the MD5 hash." }-

Look here - now I'll have nightmares !! :'(

There's little I remember about CRC32 (I recall something about Hamming codes or whatever - time to start reviewing I guess) and I never studied MD5, leave alone SHA1 which I never heard of.
But the question is, whatever the authentification method used, could a Trojan modify a file in such a way that:
1) Hash is unchanged
2) The modified code within is still viable, and can carry out whatever misdeeds it's intended for?

Second, as far as I know, Personal Firewalls use MD5 hashing - at least the most common ones we all know of. Can U cite any other firewall (for PC !) that uses SHA1 ?

[gkweb]

-{ Quote: "
But the question is, whatever the authentification method used, could a Trojan modify a file in such a way that:
1) Hash is unchanged
2) The modified code within is still viable, and can carry out whatever misdeeds it's intended for?
" }-

1) it's possible if we are talking about CRC32 chesksum.
If we talk about MD5, it is sufficiently safe, althought theoricaly it is possible that two different files can have the same hash, but it still theory, i never see someone giving evidences or an example.
MD5 is widely used and trusted.

SHA,SHA-256, or SHA-512, go over this theory to ensure it's really impossible to fake a file (a trojan with same hash than a trusted app).

2) if you mean that a trojan can modify the executable code, letting it runable and still doing his usual job (+ trojan ones), it is possible (e.g viruses) but the file hash is modified.
Modifying _one_ byte give a totally different hash.


So no need for nightmares :)
you can rely on MD5.
SHA is better but require a little more ressources if you went to need to compute some at same time.

[gkweb]

From http://www.faqs.org/rfcs/rfc1321.html

-{ Quote: "
1. Executive Summary

This document describes the MD5 message-digest algorithm. The
algorithm takes as input a message of arbitrary length and produces
as output a 128-bit "fingerprint" or "message digest" of the input.
It is conjectured that it is computationally infeasible to produce
two messages having the same message digest, or to produce any
message having a given prespecified target message digest. The MD5
algorithm is intended for digital signature applications, where a
large file must be "compressed" in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem
such as RSA.

The MD5 algorithm is designed to be quite fast on 32-bit machines. In
addition, the MD5 algorithm does not require any large substitution
tables; the algorithm can be coded quite compactly.

The MD5 algorithm is an extension of the MD4 message-digest algorithm
1,2]. MD5 is slightly slower than MD4, but is more "conservative" in
design. MD5 was designed because it was felt that MD4 was perhaps
being adopted for use more quickly than justified by the existing
critical review; because MD4 was designed to be exceptionally fast,
it is "at the edge" in terms of risking successful cryptanalytic
attack. MD5 backs off a bit, giving up a little in speed for a much
greater likelihood of ultimate security. It incorporates some
suggestions made by various reviewers, and contains additional
optimizations. The MD5 algorithm is being placed in the public domain
for review and possible adoption as a standard.
" }-

[Morgoth]

-{ Quote: "if you mean that a trojan can modify the executable code, letting it runable and still doing his usual job (+ trojan ones), it is possible (e.g viruses) but the file hash is modified.
Modifying _one_ byte give a totally different hash." }-

Actually, what I meant was: can a trojan or virus modify an app in such a way that that the modified app is still executable AND yet the hash is unchanged? That's what Morris suggested, I think...

[gkweb]

exactly as i said, it depends of the algorithm you use to compute the hash.
If you check applications by a MD5 hash, no, it isn't possible.

JV Morris said :
-{ Quote: "
A Trojan writer, on the other hand, could modify the code without changing a CRC32 hash (that's almost trivial these days) or (with a bit more effort) the MD5 hash.
" }-

agree about CRC32, but disagree about MD5.

MD5 RFC :
-{ Quote: "
It is conjectured that it is computationally infeasible to produce two messages having the same message digest,
" }-

MD5 is a safe hash algorithm :)

[Phant0m]

“LnS seems to have the edge in that matter - it uses few resources, from what I've read. On the other hand, Both LnS and Outpost fail some AWFT tests, unless Explorer is given certain restrictions... LnS is also difficult to configure and sometimes leaves port 135 open by default!!!”

* Look ‘n’ Stop v2.04p2 + Latest Application Filtering Driver passes ALL AWFT tests regardless Explorer settings.
* Look ‘n’ Stop does not leave port 135 open by Default, problem is some Online web-scans falsely report 135 of being opened, that and users improperly configures rules which leaks from too…

[gkweb]

Phant0m, you are answering to who ?
Is there any reason to post on this thread ?

???

[Phant0m]

http://www.wilderssecurity.com/index.php?action=display;board=23;threadid=16981;start=15#msg106272 ;)

[gkweb]

oh ok, i missed this point, i answered to so many question that i forgot that :)

[Morgoth]

Phantom:

-{ Quote: "Look ‘n’ Stop v2.04p2 + Latest Application Filtering Driver passes ALL AWFT tests regardless Explorer settings." }-

Huh - I you say so. But leaving aside the fact this is a beta version - still not released as a final version, for who knows what reason - it still is unable to handle copycat-related leaks IN THE SAME WAY that it can handle Thermite-type leaks, ie. on the network level (from what gkweb said, this is because Thermite inject a new thread into a process whereas Copycat modifies an existing one)
SO THE QUESTION IS: when will there be an LnS release that will also be able to cope with such threats (ie. thread modification)? Of cos', I mean a FINAL version preferably, not jus' a beta one. And will this version retain all the benefits of the previous versions, ie. low CPU usage, etc... ??

[Phant0m]

Hey Morgoth

You are correct; Look ‘n’ Stop v2.04p2 with latest Application Filtering Driver is still unable to handle Copycat. Copycat method is very ingenious and technical and further-more requiring much work to detect accessing Internet Resources. Obviously, it will be easy to just prevent an application from using the involved functions without checking the fact the application connects, but this is not the way a firewall should work.
A firewall should alert the user only if the application tries to connect...

I’m sure once Frederic officially releases Look ‘n’ Stop v2.05b1 that he’ll investigate into Copycat further and release a patch, if Look ‘n’ Stop v2.05b1 doesn’t already handle Copycat ;)

As for CPU Usage; implementing NEW Features does mean little more memory requirements, but considering Frederic work to this point I’m sure it’ll not take more than necessary to offer better level Software Security… :)

[Morgoth]

-{ Quote: "Obviously, it will be easy to just prevent an application from using the involved functions without checking the fact the application connects [...]" }-

...which is what ZA does for now I guess, huh? Damn! So in a way ZA only "half-passes" the test. I wonder how long they'll wait at Zonelabs to "fine-tune" their prog... :-\

-{ Quote: "I’m sure once Frederic officially releases Look ‘n’ Stop v2.05b1 that he’ll investigate into Copycat further and release a patch, if Look ‘n’ Stop v2.05b1 doesn’t already handle Copycat" }-

What about OFFICIAL versions? Why are they so seldom released? >:( Not that I'm paranoid or something, but experience has often taught me that "beta" means "beware" (stability issues, bugs, other @$%&#! that, combined with Microsh*t Windows, can lead to ... U know what) - can't fool with that when it comes to firewalls & other security imperatives...

-{ Quote: "As for CPU Usage; implementing NEW Features does mean little more memory requirements" }-

As long as the CPU load stays low, that's what matters. But any plans for adding extra features such as privacy, anti-popup & script-blocking? These can prove extremely handy, however the only 2 decent firewalls I know of that have all these features are Outpost & ZA - I've tried both (and still do as I keep switching between at least 5firewalls, namely Kerio, TPF, ZA, LnS, Outpost). Unfortunately, both these firewalls are known to wallop huge amounts of RAM with time >:(

I know which brands to avoid, like Norton (a tad too cumbersome), Blackice (snipped - no software bashing please), ... but this still doesn't help me in choosing a final product, & sticking 2 it. These are my criteria (from the highest down):
1) Inbound protection, stealth - but they all seem to be on a par in this matter...
2) OUTBOUND protection
3) CPU & RAM usage (I value firewall protection during online gaming ;)
4) Ergonomy
5) Mobile-code blocking (esp. vbscript & javascript)
6) Popup-blocking (not critical, but much appreciated)
6) Privacy (anti-cookie).

I've had it trying to find the "perfect" firewall - which would have ALL the benefits of the others combined, minus the drawbacks. C'mon folks, it's about time someone took the final step to distinguish themselves from the pack!!! >:( :)

[gkweb]

i'm sure firewall vendors are working hard each day to improve their product, let them time ;)

About Look'n'Stop and his "beta" name (2.0.5b1) i don't think this means that the firewall has stabilities issues, i only know that it doesn't works as of now on HyperThreading CPU (P4 HT 3.2Ghz).
What about others _official_ firewalls having real issue about the loopback for instance ?

Official doesn't mean there isn't any bug, beta doesn't mean the product is buggy, it's just a word of caution.

System Safety Monitor is in beta stage too and works perfectly for me :)

[mvdu]

I agree with Morgoth - been having trouble finding a firewall that I'm really happy with. Have licenses for NIS, ZAP, and Outpost - only one thing stands out with NIS (the IDS,) but since I'm behind a router, I'm using ZAP at least until Outpost improves. And as these leak test results show, ZAP is ahead of NIS when it comes to firewall updates.

[Morgoth]

-{ Quote: "I know which brands to avoid [...] Blackice (snipped - no software bashing please)" }-

OK that may have been somewhat excessive - but an understandable outburst of anger, too >:(! I agree that no one should criticize a retail prog this way without any argument of substance - but arguments there are, in this case!! Blacklisting a leak test site's IP (cf. 'grc.com' site) to give users a false sense of security - how dare they? That's nothing short of outright TREACHERY (not to mention a cause for litigation)! So denouncing that is more than legitimate, think you not?
But anyways I'll keep that in mind from now on - I'll be nice, I promise.. ;D

-{ Quote: "I agree with Morgoth - been having trouble finding a firewall that I'm really happy with. Have licenses for NIS, ZAP, and Outpost - only one thing stands out with NIS (the IDS,) but since I'm behind a router, I'm using ZAP at least until Outpost improves. And as these leak test results show, ZAP is ahead of NIS when it comes to firewall updates." }-

In the meantime, I wonder if it's possible setting up like 6 different firewalls on a single PC that, furthermore, operates with Windows (yipes!), and all this whilst still keeping a stable system. Anyone for testing a simultaneous setup of ZA, LnS, Outpost, Sygate, TPF & Kerio ("Red Alert, Maximum Shields!") ? ;D

I don't even know if that would significantly the protection, if at all...

Unfortunately, ZA 4.5.530 's OpenProcess protection is only a makeshift solution against copycat-type leaks, pending a future release that will fully cover the issue (hopefully)...

[gkweb]

About BlackIce, i don't really trust them too because of the GibSon leaktest story...

About running different firewall in the same time, it has been well covered in DSL report forum.

In fact, many firewall root them deeply into the OS, and install drivers/hooks.
When you installed two or more firewall at same time, they could interfers each other and blocks themselves.
I already tested, i don't remember with which firewalls, but a firewall able to block a leaktest wasn't anymore able to while running another firewall with it (drivers conflicts i think).

This is why when i do leaktest testing, i have to uninstall a firewall and reboot before installing another one.

However, i think it's mvdu which pointed that out, you "could " find 2 firewall "apparently" running fine together, but no way to ensure that they doesn't conflicts with each other.

So 6 firewall... ;D

At the end, about Copycat, don't worry, for now no firewall pass it, it's like WallBreaker, you must use application monitoring feature/software to block them.

[Paul Wilders]

Morgoth,

-{ Quote: "OK that may have been somewhat excessive - but an understandable outburst of anger, too" }-

Anger can be understandable - then again, emotions should never prevail above common sense in this particular context. Based upon intellect, you are fully entitled to express your personal opinion. In case you dislike software X or Y, simply state so - no need for extreme outbursts ;).

regards.

paul

[mvdu]

Indeed, I had to do a clean install of XP - I'm not sure what caused it (could have been the combination of NIS and ProcessGuard or a bad uninstallation,) and since I don't know, no more 2 firewalls for me. It will be ZAP, NIS, or Outpost. Maybe gkweb can add BlackICE to his leaktest results.

[gkweb]

If BlackIce firewall is still in fact a sandbox software, i can't.

[mvdu]

It still is. I've noticed that it has trouble with PCAudit, FireHole, Wallbreaker, and Copycat; and isn't perfect with AWFT (I think loses 1 point - the first point) - but it has improved.

[Morgoth]

-{ Quote: "no need for extreme outbursts " }-

A vaster choice of more... expressive emoticons would be a suitable alternative ;D