Excellent Explanation of Leopard’s Firewall Behavior

Thomas Ptacek | November 1st, 2007 | Filed Under: Apple, Uncategorized

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. It’s still a mess.

Rich seems to have the mysterious test case that demonstrates code signing; let’s see if he’ll give us a step-by-step on it!

Viewing 24 Comments

    • ^
    • v
    Hey Tom,

    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.
    • ^
    • v
    The biggest weakness is the confusion, inconcistency and non-trust the current implementation generates.

    I also don't understand why a statement like "_does seem_ to block actual connections" actually refutes anything at all.
    • ^
    • v
    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.

    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.
    • ^
    • v
    From what I've tested, this seems to create a big problem for interpreted languages. If the user allows python (because he is running some python based server), in the future any other python script will be able to create listening sockets, with no restrictions (the same goes for perl)...
    • ^
    • v
    Bruno: This is a problem with similar designs too. A lot of what runs through browsers is of-course interpreted too.

    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?
    • ^
    • v
    You write:
    -----
    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
    • ^
    • v
    CORRECTION for the simple test:

    connect with:

    nc [IP] 1414

    bye, ju
    • ^
    • v
    Programs run as "root" can bypass the socket firewall. Programs run as "root" can also reconfigure the firewall.

    Your "netcat" test doesn't work if you take the "sudo" out of the command line.

    What have you actually proven, Juergen?
    • ^
    • v
    Thomas:
    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
    • ^
    • v
    Then ntpd can also reconfigure the firewall. What's your point?

    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.
    • ^
    • v
    (It's always possible that I'm wrong, too. I will concede when that is demonstrated to me with evidence.)
    • ^
    • v
    I am always capable of admitting when I am wrong. And maybe I am. I certainly was sometimes in the past. But now I really do not understand where I am wrong in your opinion.

    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
    • ^
    • v
    Clearly, where you have demonstrated that you can retrieve NTP dates from a Leopard system even when the system is configured to "block all incoming connections", you have proven that there is an undocumented exception to the Leopard firewall.

    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?
    • ^
    • v
    I am not going to argue in favour of something I did not say (like comparing to Tiger). This is about facts. And mine seem to be right and yours seem to be wrong.

    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 ...
    • ^
    • v
    Clearly if you select the tests and selectively publish the results, you can draw any conclusion you want. I'm not accusing you of doing so deliberately, though.

    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.
    • ^
    • v
    ... also, the "netcat" example you provide is very misleading.
    • ^
    • v
    Thomas I am sorry, with all due respect:

    > 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 ?
    • ^
    • v
    The UI definitely sucks.

    I think the best way to sum the situation up is that the Leopard firewall is "ambitious and weird".
    • ^
    • v
    Note also that Jeurgen has been quoted in the press saying that the Leopard firewall contributed to the RSPlug trojan, and is an actual vulnerability.

    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.
    • ^
    • v
    I think the point is that in all other OS/Firewalls, you have to re-configure the firewall to allow those connections, not just run an app as root that uses a particular port.

    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
    • ^
    • v
    Yes, processes running as root can reconfigure the firewall if they so choose.

    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.
    • ^
    • v
    Ok, I guess I can add some irrelevant comments of my own: Core Force implemented the idea of a per process stateful firewall some years ago on Windows systems. For that purpose we ported OpenBSD's PF to Windows. We found out that to make things work properly we needed to filter *both* below the IP stack at the shim NIC driver level and above it at the socket layer. The reason was that at the driver level you have no "process context" whatsoever and at that IRQL is not very advisable to play around with kernel memory to figure out which process a packet belongs to. On the other hand it is not a great idea to have an outbound connecting application block on connect() just because your NIC layer filter is dropping the outbound SYNs. Getting this right in a generic way for all types of applications is not as simply as it may seem...

    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.
    • ^
    • v
    I think the language used here is too broad and misleading. Everyone who doesn't know better thinks, and everyone who does know better tries to make believe, that on a UNIX system or any other establishing an IP connection, delivering a packet or querying a time server means "boohoo the system is wide open everyone can modify the root password".

    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.
    • ^
    • v
    In general, I agree with Thomas P. Heise's analysis was short and lacked quality. However, that is not to say it was untrue. I am concerned that the community gives some much attention to these claims, given I haven't seen one post on anything regarding default ipv6/ip6fw configurations in 10.5. Has anyone looked at an "sudo ip6fw list" after installation? Are we to assume that if OSX passed this firewall management application test that Heise conducted, OSX gets a security thumbs-up from a "reputable" group. As a potential consumer of your services, I would advise caution and very specific clarity about the work you (the collective you)publish. The world does pay attention, although I am disappointed that nothing was cross referenced for quality in this case, and publishers like zdnet and BBC news just blindly echoed someones half-baked work. I was of the opinion that this would be a decent exchange on the security architecture of 10.5+. This has just amounted to a "your wrong admit it/I'm right admit it" conversation without any well thought analysis or quality surrounding the topic of this post!! I'm getting frustrated with the security community today in combination with the blogosphere and the thoughtless race to a first post. In the end, it all comes out in the wash. Heise, take it back to the lab and come back when you have completed a decent research paper with some QA and provide us with something worth our time.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus