Serious bugs in Jetico 1.0.1.61 and Kerio 2.1.5

I like both Jetico and Kerio 2.1.5 firewalls because they are free and very resource-friendly compared to many other firewalls. However, I have problems with both.

Jetico 1.0.1.61 bug: it works fine initially and then gets confused about process identification *after* certain security events. For example, with Jetico active, I run Opera 8.5 which initially works fine. I then open a command prompt. I then run my own program that generates a security alert (modifying one of ANY another process, totally unrelated to Opera) and tell Jetico allow it. After this, Jetico issues a network alert everytime Opera tries to access a website, but Jetico identifies Opera as "CMD.EXE".

Jetico bug #2: I already replaced Jetico with Kerio 2.1.5 so I cannot confirm it but I think Jetico's firewall doesn't differentiate between different programs launched from the command prompt. Note that in the above example, Opera was launched normally (start menu) so this is a separate issue.

Kerio 2.1.5 bug (Firewall Engine Version: 2.1.5 and Driver Version: 3.0.0):
try this simple test:
1. in command prompt, try "ping www.freebsd.org" and you'll correctly see:
"Pinging www.freebsd.org [216.136.204.117] with 32 bytes of data:
Reply from 216.136.204.117: bytes=32 time=67ms TTL=48"
...
2. click "Stop all traffic" from the kerio tray icon menu
3. in command prompt, try "ping -l 5000 www.freebsd.org" and you'll see that network activity isn't blocked:
"Pinging www.freebsd.org [216.136.204.117] with 5000 bytes of data:
Reply from 216.136.204.117: bytes=5000 time=222ms TTL=48"
...

So basically, Kerio 2.1.5 seems incapable of preventing a local program requesting and then receiving response from a remote machine on the internet even while Kerio's "Stop all traffic" option is selected.

Are there there any solid alternatives to these 2 firewalls? I just want something very resource-friendly to work well on Windows 2000 sp4. I want the firewall to do its core functionality well instead of bundling a bunch of non-firewall features that I can get from other products.

[FastGame]

Kerio 2.1.5 bug (Firewall Engine Version: 2.1.5 and Driver Version: 3.0.0):
try this simple test:
1. in command prompt, try "ping www.freebsd.org" and you'll correctly see:
"Pinging www.freebsd.org [216.136.204.117] with 32 bytes of data:
Reply from 216.136.204.117: bytes=32 time=67ms TTL=48"
...
2. click "Stop all traffic" from the kerio tray icon menu
3. in command prompt, try "ping -l 5000 www.freebsd.org" and you'll see that network activity isn't blocked:
"Pinging www.freebsd.org [216.136.204.117] with 5000 bytes of data:
Reply from 216.136.204.117: bytes=5000 time=222ms TTL=48"

Are you sure the "ping -l 5000 www.freebsd.org" is correct ? it does nothing for me.

[Kerodo]

Originally Posted by RWA

Are there there any solid alternatives to these 2 firewalls? I just want something very resource-friendly to work well on Windows 2000 sp4. I want the firewall to do its core functionality well instead of bundling a bunch of non-firewall features that I can get from other products.

One popular solution amoung people I know is to run CHX as your basic packet filter. CHX has great features, however, there is no traditional outbound control. So, in place of the usual outbound control, you can also run Antihook, which should catch anything before it even gets to connect outbound. The CHX/AH combo is a pretty good one.

Here's a link to CHX (it's free also): http://www.idrci.net/ Read thru the online docs to get a good overview of it. It's an excellent program. And you just can't beat it for low resource usage. It runs as a kernel service.

Then there is also Harden-It and Samurai to add a little system hardening on top of the above. With all in place, things are pretty tight.

I don't think CHK is free anymore. I clicked on PRODUCTS, then PACKET FILTER. At the bottom of the page below the DOWNLOAD TRIAL button, it says:

"* The trial version will expire in 30 days."

[Kerodo]

Yes, CHX is definitely free. You just need to register and obtain a code. But it is free. I believe even the new version 3 (which is currently in beta) is also free. At their site, go to Products, Packet Filter, Registration.

[noway]

Originally Posted by RWA

...So basically, Kerio 2.1.5 seems incapable of preventing a local program requesting and then receiving response from a remote machine on the internet even while Kerio's "Stop all traffic" option is selected...

That's interesting...on my machine your example works for ping packets 1473 bytes and larger. Whether this is critical for someone is open for debate...I guess if one unwittingly downloads a trojan, runs it, and the trojan pings various machines hoping to find a machine vulnerable to ping packets...I don't think the "stop all traffic" would allow TCP/UDP outbound/inbound to pass. I was surprised to find that even with filter rules blocking ICMP, that these particularly large ping packets were still sent out and a response received. It would be nice to have the bug fixed, but 2.1.5 is no longer in development. Let us know if you ever see/read anything like this for TCP/UDP. Every firewall I have ever used has bugs...you can move to another firewall but the new one will not be free of issues either (ie. BSODs, memory leaks esp. with p2p, poor/quirky/bloated GUI, high memory use under normal circumstances, unable to block apps that use a local proxy-->I think I have covered the most popular current personal firewalls!) so if you switch software every time you find a bug it is a vicious circle and you may be back to where you started.

I read that Kerio 2.1.5 also has the fragmented packet problem with TCP and UDP--not just ICMP. So this isn't a problem that should be ignored simply because we love Kerio 2.1.5's price, speed/footprint, and GUI. For example, this flaw can be used by an attacker to determine that your pc exists (which is one important reason we usually DROP packets instead of REJECTing them).

I found a workaround and confirmed it on Windows 2000 so I don't have to lose all my beloved Kerio 2.1.5 rules. I'll post in new thread.

[Rmus]

Originally Posted by RWA

I read that Kerio 2.1.5 also has the fragmented packet problem with TCP and UDP--not just ICMP. So this isn't a problem that should be ignored simply because we love Kerio 2.1.5's price, speed/footprint, and GUI. For example, this flaw can be used by an attacker to determine that your pc exists...

So, what would happen then? What could an attacker do, knowing that you exist on the internet at that IP for that session?

regards,

-rich
________________
~~Be ALERT!!! ~~

[Kerodo]

Originally Posted by RWA

I read that Kerio 2.1.5 also has the fragmented packet problem with TCP and UDP--not just ICMP. So this isn't a problem that should be ignored simply because we love Kerio 2.1.5's price, speed/footprint, and GUI. For example, this flaw can be used by an attacker to determine that your pc exists (which is one important reason we usually DROP packets instead of REJECTing them).

There are many who say that a hacker has ways to tell if you're there even when you are stealthed on grc.com and so on. So they say that all the stealth business is complete nonsense. Just visit the newsgroup comp.security.firewalls and ask there about it. You'll get some old hands lecturing you on what a waste of time stealth is..

[FastGame]

Guess I'll say this again.......

"ping -l 5000 www.freebsd.org" with Kerio 2.1.5 does nothing, with "Stop All Traffic" my Kerio does exactly that, nothing gets through.

>>>So, what would happen then? What could an attacker do, knowing that you exist on the internet at that IP for that session?

They could focus on mounting attacks targetting your machine instead of moving on to the next random ip address. For more specifics, ask an attacker but this is probably the case in general:

Common tactic:

choose predefined ip address list (maybe targeting specific cable/dsl ISP)
loop:
if computer detected at current ip address, then
try os-fingerprinting, latest 0-day/unpublished vulnerabilities, dns poisoning, and more
else ignore "dead" ip address
get next ip address
repeat loop

Fortunately, I have a workaround which allows me to continue using Kerio 2.1.5 and not have to worry about fragmented packets--and without running yet-another-process that would eat resources or switching to more bloated firewalls. With the workaround, the previously successful large packet pings no longer work with "Stop all traffic". Successfully tested on Windows 2000 with "ping -l 5000" from the Kerio-protected pc and "ping -s 5000" from a remote Linux box. Haven't tested yet using other protocols, but will try as soon as time allows so I can post the solution with more confidence. Good luck.

Originally Posted by FastGame

Guess I'll say this again.......

"ping -l 5000 www.freebsd.org" with Kerio 2.1.5 does nothing, with "Stop All Traffic" my Kerio does exactly that, nothing gets through.

Odd..

Can you cut/past the output from your ping command?

What OS are you running? I tested with Windows 2000 sp4.

What ping.exe are you running? Mine is c:\WINNT\system32\ping.exe

What does your Kerio About box say? Mine says "Firewall Engine Version: 2.1.5 and Driver Version: 3.0.0". The version of Kerio 2.1.5 I used was downloaded yesterday directly from kerio.com.

And finally, did you successfully resolve the www.freebsd.org ip address before "Stop all traffic" was enabled? ping needs to know the ip address.

[pcalvert]

Originally Posted by RWA

Kerio 2.1.5 bug (Firewall Engine Version: 2.1.5 and Driver Version: 3.0.0):
try this simple test:
1. in command prompt, try "ping www.freebsd.org" and you'll correctly see:
"Pinging www.freebsd.org [216.136.204.117] with 32 bytes of data:
Reply from 216.136.204.117: bytes=32 time=67ms TTL=48"
...

This works as expected.

Originally Posted by RWA

2. click "Stop all traffic" from the kerio tray icon menu
3. in command prompt, try "ping -l 5000 www.freebsd.org" and you'll see that network activity isn't blocked:
"Pinging www.freebsd.org [216.136.204.117] with 5000 bytes of data:
Reply from 216.136.204.117: bytes=5000 time=222ms TTL=48"
...

This did not work for me. After a long delay, I got this response:
"Unknown host www.freebsd.org."

At least for me, KPF is working fine. I suspect that you may have a problem with your installation and/or configuration.

Phil

[Rmus]

Originally Posted by RWA

>>>So, what would happen then? What could an attacker do, knowing that you exist on the internet at that IP for that session?

They could focus on mounting attacks targetting your machine instead of moving on to the next random ip address.

The attached image shows a probable worm attack looking to sneak in a trojan.

I don't see whether or not it matters that an attack is aimed at a particular IP address, or is random, as long is it is blocked. The IP address will change on next login anyway.

regards,

-rich
________________
~~Be ALERT!!! ~~

[Rmus]

Originally Posted by Kerodo

... You'll get some old hands lecturing you on what a waste of time stealth is..

It's also not permitted according to IETF standards

See:

http://homepage.ntlworld.com/robin.d.../security.html

(scroll to "Stealth-mode Firewall)

"This hyper-paranoid approach to security causes some difficulties.
For a start, Internet standard RFC 1122 states categorically about ICMP Echoes (ping):

3.2.2.6 Echo Request/Reply: RFC-792

Every host MUST implement an ICMP Echo server function that receives
Echo Requests and sends corresponding Echo Replies."

Also:

"A commonly heard objection to allowing ICMP Echo Replies is that it gives
away information to hackers that there is a live connection on this IP
address. Such objections are not well-founded, and can be safely ignored.
There is no evidence in practice that any hacker has been aided by the
presence of an ICMP Echo Reply. Hackers do not typically write code that
tests an address with ICMP Echo before launching a hostile probe: they
always send the hostile probe directly: either it works or it doesn't, and
information from ICMP adds nothing to the analysis."

Kerodo, you will remember this:

http://www.issociate.de/board/index....&th=7012&rid=0

"Some firewalls make a virtue out of sending no reply, and they even
invented a new term for it: "stealth". This may be great for a marketing
brochure, but is quite useless in the real world, especially if you have any
service at all open on your machine, with any protocol. Even worse, this
breaks some RFC's - not that that ever stopped the marketroids."

regards,

-rich
________________
~~Be ALERT!!! ~~

[FastGame]

This is with Kerio set to "Stop All Traffic" http://img115.imageshack.us/img115/7...ders2xk.th.jpg And this is with Kerio set normal http://img115.imageshack.us/img115/8...ers25jf.th.jpg

Maybe I did something wrong ?

[Kerodo]

Well said Rmus...

CHX+Kerio 2.15 can be combined to make your system totally stealth and have outbound protection as well, CHX takes very little resources so the impact on the system is nil. I have done it like that for months when I was using Kerio 2.15

[ghost16825]

Firstly, I'm guessing RWA was using the DNS Client Service. www.freebsd.org already had a resolving enty in the cache so ping didn't fail to resolve the domain name. (Which is what always happens when Disable traffic is set)

I can almost say any ICMP data size will fail if the address needs to be resolved (when Disable traffic is set). However I did get some weird input on one occasion when pinging the domain name (one reply):

Pinging www.freebsd.org [216.136.204.117] with 32 bytes of data:

Reply from 216.136.204.117: bytes=32 time=327ms TTL=50
Request timed out.
Request timed out.
Request timed out.

An attempt with a larger size and only the the IP address resulted in also strange behaviour:

Pinging 216.136.204.117 with 5000 bytes of data:

Request timed out.
Request timed out.
Reply from 216.136.204.117: bytes=5000 time=2732ms TTL=50
Reply from 216.136.204.117: bytes=5000 time=404ms TTL=50

Then Kerio seemed to allow all replies:

Pinging 216.136.204.117 with 5000 bytes of data:

Reply from 216.136.204.117: bytes=5000 time=448ms TTL=50
Reply from 216.136.204.117: bytes=5000 time=407ms TTL=50
Reply from 216.136.204.117: bytes=5000 time=404ms TTL=50
Reply from 216.136.204.117: bytes=5000 time=421ms TTL=50

on my machine your example works for ping packets 1473 bytes and larger

This is a very important point/clue. What this points to is....you guessed it...behaviour due to fragmented packet handling.

Ethernet has a Maximum Transmission Unit of 1500 bytes. 20 bytes are reserved for the IP header and 8 bytes are allocated for the ICMP Echo Request header. Windows by default (registry entry) I believe has a MTU of 1500 bytes for all non-local addresses. What happens when the total packet size you want to send is above this? You guessed it - fragmentation. And Kerio 2x doesn't seem to handle fragmentation well. I think that's the problem.

[Rmus]

Originally Posted by ghost16825

... And Kerio 2x doesn't seem to handle fragmentation well...

What types of exploits could occur due to this?

Any known occurrences that you are aware of?

thanks.

[Rmus]

Originally Posted by ghost16825

I can almost say any ICMP data size will fail if the address needs to be resolved (when Disable traffic is set).

OK, I did a test here.


-rich
________________
~~Be ALERT!!! ~~

[ghost16825]

Originally Posted by Rmus

What types of exploits could occur due to this?

Any known occurrences that you are aware of?

thanks.

No-one could really do much with ICMP; perhaps create an inefficient covert channel which has been done. The bigger issue is how Kerio handles TCP/UDP packets both inbound and outbound which are fragmented, regardless of size. (I don't know) If you are concerned, setting appropriate registry settings to disable fragmented packet sending and receiving might be prudent. That is, if you rarely need to handle packet sizes over the default MTU of 1500 bytes. (Which is usually the case)

[ghost16825]

Originally Posted by Rmus

OK, I did a test here.


-rich
________________
~~Be ALERT!!! ~~

That's 32 bytes though - no need to fragment it.

[Rmus]

Originally Posted by ghost16825

If you are concerned, setting appropriate registry settings to disable fragmented packet sending and receiving might be prudent. That is, if you rarely need to handle packet sizes over the default MTU of 1500 bytes. (Which is usually the case)

I'm not sure - I've seen posts about this but have never seen an example of how this could be exploited.

Originally Posted by ghost16825

That's 32 bytes though - no need to fragment it.

EDIT: OK, I misunderstood. Pinging with 1500 bytes went through.



-rich
________________
~~Be ALERT!!! ~~

[ghost16825]

Originally Posted by Rmus

I'm not sure - I've seen posts about this but have never seen an example of how this could be exploited.

I haven't seen conclusive proof that Kerio 2x allows fragmented TCP/UDP regardless of the ruleset and/or Stop Traffic option only some limited tests that say fragmented packets are not logged.