-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/988/excellent-explanation-of-leopards-firewall-behavior/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
Here's how to test the Skype/signing. Turn the firewall on in block all mode. Launch and close Skype as many times as you want. Turn it on to Set access mode and open your console. Launch Skype, slick on allow access, close, relaunch and it fails. You'll see the Check 1 Failed message in the console. It was when I Googled that error that it put me on the track of the firewall and code signing. Re-installing Skype tells the OS it's a new app, and you'll be prompted on launch again to allow access and it will work. Turn off application control on the firewall and Skype will work (you still might need to reinstall if the code was signed since that process runs no matter what the setting on the firewall, it's just that the application control mode is a trigger for application signing).
Next step is to dig in and find where the signatures are and track that, but I won't be able to get to it for at least a few days since I need to get caught up with work that pays the bills.
Mac security is fun, but as you know no one seems to pay for it.
I also don't understand why a statement like "_does seem_ to block actual connections" actually refutes anything at all.
The reality appears to be that it is blocking traffic --- albeit in a manner that gives misleading port scanning results --- and that there are some straightforward (but very poorly documented) exceptions to the firewall's policy.
The Leopard firewall is very different from the Tiger firewall. It's enforced at the socket layer in the kernel, not at the edge between the IP stack and the Ethernet driver. It's an ambitious, weird, and probably frustrating design. But it isn't stupid, and, to date, nobody has disclosed a real vulnerability resulting from it.
I join the chorus of people demanding better UI and more documentation for the firewall, but don't buy the argument that it's a real step back in OSX security.
One example is Zone Alarm on Windows, which has been taking this approach possibly longer than anybody.
In fact, can anybody explain to me what if any major difference there is in the Mac OSX firewall approach from Zone Alarm?
-----
The Heise article could easily lead you to believe that the Leopard app firewall isn’t blocking any UDP, or is failing to block TCP connections.
------
Yes it can -- because this actually the reality.
Certain signed applications can accept incoming connections on TCP or UDP ports even if you block everything (including this so called "stealth mode" which only blocks ICMP).
----
The reality appears to be that it is blocking traffic — albeit in a manner that gives misleading port scanning results — and that there are some straightforward (but very poorly documented) exceptions to the firewall’s policy.
----
Yes -- the port scanning results are misleading -- but the other way round. Rich Mogull relies on them, not me.
The ports are still open -- even if you choose "Block all incoming connections" and "stealth mode".
To check that, you have to actually talk to a service. That is what I did. And I was able to query the ntp daemon with "ntpdate " over the internet. Try it for yourself.
One more simple test. Block everything, activate "stealth" and start a simple demo server like
sudo nc -l 1414
and then connect from a different machine with netcat or telnet like:
nc 1414
Evrything you enter on one side is echoed on the other -- the port is open.
bye, ju (heise Security)
bye, ju
connect with:
nc [IP] 1414
bye, ju
Your "netcat" test doesn't work if you take the "sudo" out of the command line.
What have you actually proven, Juergen?
I have proven exactly what I claimed (and you refuted up there): That the even if the firewall is set to "Block all Incoming connections" plus stealth, it does not do so and ports can be open despite all firewall settings.
I know this is limited to processes that run as root.
But ntpd *does* run as root -- check with "ps aux | grep ntp".
The result: the UDP ntp port is open by default and all the time, despite all firewall settings. You can easily validate that claim by doing "ntpdate [IP]".
bye, ju
With all due respect, let me lob this hand grenade: I think you were just wrong in your analysis, and you're going to have to concede at some point.
The Leopard firewall is weird, to be sure. It may even be a step backwards from Tiger. But it is not full of gaping holes.
To make this clear. Here is the essence of my analysis:
--
Take a Leopard system in a default installation. Now enable the firewall to "Block all icoming connections" plus stealth. Connect it to a network. Check
sudo ntpdate [IP]
from an external machine. You will get something similar to:
6 Nov 17:25:51 ntpdate[5678]: step time server 10.10.22.76 offset -13.548175 sec
This proves that the ntp port is still open, the time service is still accepting connections from the outside and everybody can still talk to it. So the firewall does not do what it claims.
--
Please tell me, what exactly is wrong with that claim?
And please don't argue with "appears to". Proof your statements with reproducable evidence, as I did.
bye, ju
Clearly, where you have demonstrated that "root" can bind a TCP or UDP port with "netcat", and accept incoming connections even when the system is configured to "block all incoming connections", you have proven the existence of another undocumented exception.
However, while you noted that these services did run as root, you did not note that they *had to run as root* in order to bypass the firewall.
This is not an insignificant detail. Your findings of fact are valid, but your analysis of them is not.
That's because a program that runs as root necessarily has the ability to reconfigure the firewall. There is little extra security to be had from operating system features that attempt to defend the socket firewall against "root", because the kernel itself cannot defend against "root".
My challenge to you is to respond to this argument: that Heise has not demonstrated clear flaws in the Leopard firewall, but rather ways in which Leopard's firewall is different from Tiger's and mainstream built-in firewalls.
Your article stated that Leopard's firewall "failed in every test". You have made the extraordinary claim, and I'm asking you to support it with evidence. In what ways is a system with the "block all connections" Leopard firewall known to be less secure than a Tiger system with the same policy?
But the last one is easy: The article starts with:
---
Initial functional testing has already uncovered cause for concern.
---
The functional tests we performed were:
1) Is it active by default? failed
2) If I set it to "Block all incoming conncetions", does it block all incoming connections? failed.
3) If I set it to "Set access to specific services and programs", does it refuse access to services that are not in that list? failed
---
I think after this, it is a reasonable summary to say, it failed in every test. (Note: I do not claim, that this is a complete test of a firewall, as I said it was "initial functional testing").
But please look at the top of this page:
---
Some of Rich Mogull’s new writeup on what the 10.5 firewall does seems to refute Heise’s article: without “stealth mode” enabled, services show up in port scans but can’t actually be used.
---
You just agreed, that the time service is usable. So this is proven wrong. And I still have not seen a single fact, that "refutes" my article.
bye, ju
PS: I am "off" now ...
Here's what we can say about the Leopard firewall now (none of which we can say based on a single citable source):
* It works differently from Tiger
* It only peripherally uses the BSD IPFW firewall
* It is bound principally to the socket layer and coupled with the execution of actual programs
* There are undocumented exceptions to the firewall
* Programs running as root can elect not to be bound by it
I don't think you can justify the argument that this is a "failure", although you can easily argue that it's less optimal than the Tiger firewall.
> There are undocumented exceptions to the firewall
This reads like "its not a bug it's a feature" an firewall that has such inconsistent results does not help a _consumer_ OS, it does not promote trust in any way. For a consumer when it says "Block all connections" it better does.
I see where you both are coming from, Juergen from the Consumer perspective (Trust your firewall ?) and you from the expert perspective (If you know all details and every "undocumented exception" you can still estimate the risk)
Could you both agree that the firewall is currently very inconsistent ? Misleading ? Inappropriate for a consumer OS ?
I think the best way to sum the situation up is that the Leopard firewall is "ambitious and weird".
I'm not the one making extraordinary claims here. And extraordinary claims require extraordinary evidence.
The evidence we have now is pretty dubious. There is no operating system in which an admin user cannot accept connections regardless of firewall policy.
I think Apple is probably trying to lower their support costs by making their firewall "user friendly", but I can see where Jeurgen can be justified in saying this is a good angle for malware authors who now don't need to code the firewall rule changes for inbound connections, just spawn a process that listens on that port and voila!
-JP
No, well behaved code will not do so.
If I tell my firewall "block ALL incoming connections" my biggest reason is that I don't believe ntpd, sshd, httpd, or whatever are bug-free.
For me, it's not about malicious code running as root. It's about buggy code running as root.
Buggy code listening to a hostile network begets malicious code.
Incidentally, in the process we also found out that many (most) Windows applications have terrible behavior due to bad coding practices for both network and file system access, this *will* become evident when you attempt to do per-process sandboxing and may explain some of the security shortcuts taken to prevent apps from breaking entirely.
In the end, the hardest part of all was always per application policy settings: How do you specify strict security policies for thousands of possible applications that may be run under many different environments by users with different risk tolerance thresholds. We did not find a satisfactory solution to this problem with Core Force and I think neither did SELinux, AppArmor or systrace.
@Thierry: I agree with your consumer's viewpoint remark but I would add that a typical endpoint's user has an extra implicit expectation: when she selects "block all incoming connections" she really expects "block all incoming connections but don't break any existing functionality" and I think therein lays the reason for the subtle exceptions to the general rule. They probably found that blocking certain apps cause severe breakage and instead of fixing the apps to work properly they decided to just add them to the list of exceptions
Final irrelevant comment: "stealth" is overrated and it breaks stuff. Not being "stealth" is not a bug.
That is plain wrong. Only way to "infiltrate" such a system is a) REXEC/RSH, FTP, file services etc. is allowed, running, insecurely configured and has bullsh*t passwords set up, b) exploiting a buffer overflow or other bug (first one easy to avoid, second unfortunately not so). Which is also true for any other operating system. Just because you send a packet, you cannot "take over" the system, since you need a PROCESS listening on the other side that answers and does what you like. If all that process does is to answer you with a packet containing the time in Castrop-Rauxel, good luck at "taking over" that system, or "accessing security relevant data".
The only thing a good firewall does is that it TELLS you when you have been fool enough to make some unknown Nigerian million dollar transfer program or alike run on your computer, when it tries to open connections. And it prevents foolishly configured internet services from answering. Ok, that is a valid enhancement since bug exploitations might allow to run code as root. However, if that code can via some API function change the firewall configuration or entirely shut it down, your nice shiny sandbox just imploded. Unless you have an undocumented, kernel side firewall that has hardcoded rules and needs recompiling the code in a restricted mode to change anything, with no front end and no script changes possible, a well made worm can still overcome anything but a hardware firewall once it runs on the local system and has root rights.
Rule of thumb: don't open attachments, don't have autoplay stuff configured, use a restricted user to go into internet, securely configure services to not allow remote logins etc. That way, I did not have a worm in years, with a freaking W2K system (running the OS on NTFS with access rights taken away from my internet user). A firewall cannot protect you from intrusions if you still go online using mail and internet browsers watching videos and presentations, it just tells you when you f'd up.