Slashdot Mirror

← Back to Stories (view on slashdot.org)

OS X Leopard Firewall Flawed

Posted by kdawson on from the block-what-i-say dept.

cycoj writes with a report in the German IT magazine Heise, taking a look at the new OS X Leopard firewall. They find it flawed. When setting access to specific services and programs to only allow SSH access, for example, they found that a manually started service was still accessible. From the article: "So the first step after starting Leopard should be to activate the firewall. The obvious choice to do so is the option to 'Set access to specific services and programs,' which promises more control over network traffic. Mac OS X automatically enters all shared resources set up by the user, such as 'Remote login' for SSH servers, into the list of accessible resources... However, initial functional testing quickly dispels any feeling of improved security. A service started for testing purposes was able to be addressed from outside without any difficulty. The firewall records this occurrence... Even with the firewall set to 'Block all incoming connections' ports to netbios, ntp and other services were still open... Specifically these results mean that users can't rely on the firewall."

4 of 300 comments (clear)

  1. OS Firewalls by nurb432 · · Score: 5, Insightful

    Shouldn't be used in the first place. You really need an external dedicated firewall if you want to pretend to be safe.

    --
    ---- Booth was a patriot ----
  2. Re:Investigation flawed, more like by kebes · · Score: 5, Insightful

    if Leopard trusts the service (it's a root process, or it's signed with an acceptable crypto signature), it will have access through the firewall. Since Leopard ships with cryptographically-signed binaries/packages, I guess I'm not seeing the problem The problem is that the user asked the OS for a certain action ("block everything") and the OS didn't implement that action. This is basically a case of the OS saying "don't worry, I'm smarter than you and I know what to do"... which isn't a good policy when it comes to security. If a user tries to activate a firewall policy (because they happen to know a certain service is insecure, or not needed, or whatever), then the firewall should implement that policy.

    You could argue that the 'Block all incoming connections' is badly worded, but you could argue that reading the documentation for a new firewall would be a useful thing to do as well. If the situation is indeed as you describe (that the problem here is just that the firewall is allowing certain connections that it "knows" are okay) then you're right: this isn't a security vulnerability, but rather a case of poor UI design. The UI is saying "I'm blocking all connections" even though it isn't. You're also right that in principle the user should educate themselves about their software. However the software should, as much as possible, not misrepresent what's going on. Saying "blocking all connections" and then allowing something to connect is a recipe for security mistakes.
  3. All tests were run on localhost by hbp4c · · Score: 5, Insightful

    Perhaps I missed something...

    It looks like every test that was ran was run from the local machine. The tester set "block incoming connections" not "block local connections" and/or "block outbound connections"

    If you lsof, you're going to see ports open to localhost, unless the firewall is specifically dropping packets to 127.0.0.1.

    ntpdate is an ntp client tool, so it makes an outbound connection instead of an inbound connection.

    nmblookup actually warns the guy testing this - it realized that 192.168.69.21 was the local interface, so it responded as "localhost" instead of the samba name!

    The nmap test was the only tool that specifically checked a non-localhost IP, and it's not clear to me if it actually checked the localhost interface cleverly or actually sent packets out and through the firewall.

    As I said, perhaps I missed some critical fact. However, I would put more credibility in the tests if the tester had used a 2nd machine on his subnet to nmap the leopard firewall.

  4. Re:Never put your eggs in one basket. by ScytheBlade1 · · Score: 5, Insightful

    Really good thing that my linux software firewall is stored on a read-only filesystem then, and only allows login via SSH hostkeys.

    I made my initial post pretty quickly, and likewise screwed up some things.

    What is the difference between a software and a hardware firewall anyways? Heck, what is a firewall? There are so many countless ways of defining a 'firewall' that the average home router you can pick up at your local grocery store is advertised as a "router/firewall." Just because it's embedded suddenly makes it less of a software firewall, and more of a hardware one?

    As mentioned, my router has a read-only root file system. It's also running a complete linux distro. Is this a hardware or software firewall?

    Further, it does stateful packet inspection (four-ish lines of iptables commands? Worth $40+ on 'firewall' devices?), QoS (both host and service based), and it does this all through a transparent ethernet bridge. Then I have an admin ethernet jack, which requires IPSEC connectivity before you can touch the internal ports (22, 80).

    It's a complete linux distro, so it's software. It's 100% embedded, so it's hardware.

    As mentioned, other routers are embedding linux. Cool. Hardware or software? More secure, or less? More capable? Or less capable?

    Classifying 'software firewalls' as 'insecure' and classifying 'a cheap Linksys Firewall/Router' as 'secure' is kinda scary in all truth. Well, mostly just wrong. Firewalls are too generic now - just because it says 'firewall' on the front, you're supposed to think that you're safe from 'hackers.'