OS X Leopard Firewall Flawed

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."

Never put your eggs in one basket.

[jellomizer (103300)]

Leson 1.
Never Trust Software firewalls. Software firewalls are only should be used in protection against "internet static" attacks. Where just random worms and viruses are trying to get in. Software Firewalls
Are normally bad against direct attacks from real hackers. Because there are so many ways to trick the user to install software to get around it...

Lesson 2.
Never trust anyone to keep security up. Apple, Microsoft, Linux Distributions, even Open BSD they are all made by humans and humans make mistakes and forget to check out things...

Lesson 3.
Always keep a hardware firewall even if it is a cheap Linksys Firewall/Router they will double up protection and keep your system relatively safe.

Lesson 4.
Never assume that you are 100% safe. There are always ways around things...

Re:Never put your eggs in one basket.

[MBCook (132727)]

I'll agree with most of that. I've got a Mac, and it's running Leopard (yeah!). At work I surf behind a real firewall, a Watchguard I think. At home, I'm behind my Linksys. I could run no firewall and be OK. That said, I leave it on for one simple reason: I can go to other people's networks without having to think about turning the firewall on. This way if I were to go to Starbucks or something, I'd be much more safe from so guy a few tables over (malicious or just bot-infested). I don't expect things to be perfect. I don't expect a software firewall to be as good as a hardware one. It's just one more layer.

So what do I think of all this? I don't know. I saw comments somewhere the other day that claimed that these guys were just misunderstanding, but I'm not sure. I expect a firewall to block things if I tell it to though.

Re:Never put your eggs in one basket.

[by Anonymous Coward]

Couldn't you argue that more layers = more possibilities for attack vectors?
Also, FYI, a hardware firewall is just a dedicated software firewall.

Re:Never put your eggs in one basket.

[gEvil (beta) (945888)]

Also, FYI, a hardware firewall is just a dedicated software firewall.

I don't know if I buy that. I mean, one has the word "hard" in it, while the other has "soft" in it. Given the choice of the two, the "hard" one sounds far more secure.

Re:Never put your eggs in one basket.

[Sloppy (14984)]

That's why, on my computer, I a use a hardware null device. I don't trust the OS' slow software-emulated null device to properly dispose of my unused bits. You never know who might be going through your trash, piecing together private information. The performance boost is just icing on the cake.

Re:Never put your eggs in one basket.

[Cecil (37810)]

Couldn't you argue that more layers = more possibilities for attack vectors?

That would only apply if breaking one link in the chain is as good as breaking all the links in the chain - ie, if they give special accomodations to one another because they are all part of the "same network" or one contains passwords to the others or something of that nature. In this case that should not happen, thus you must break each link in succession to get through.

Also, FYI, a hardware firewall is just a dedicated software firewall.

The key word here is "dedicated". A dedicated firewall means you are not installing other software on it which could compromise the firewall itself (either intentionally or through poor design), and it also means that should a hacker somehow break into the firewall, your losses are limited as they have not also gained entry to your files, your passwords, your keyboard, your browser, etc and they cannot rootkit your PC. They only get a tiny, wimpy processor with little-to-no storage and complete network access. Dangerous, yes, but not a complete disaster.

Re:Never put your eggs in one basket.

[Zenaku (821866)]

If the the layers of security are really layers of security, then no you couldn't argue that. You have to breech the outtermost layer before you can even attack the second layer, and you have to breech that layer before you can attack the third, etc.

Re:Never put your eggs in one basket.

[toleraen (831634)]

My Linksys router runs a Linux based software firewall.

Re:Never put your eggs in one basket.

[ScytheBlade1 (772156)]

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.'

OS Firewalls

[nurb432 (527695)]

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

and now for something completely different...

[Tumbleweed (3706)]

"It's not much of a firewall, is it?"

"Finest on this subnet, sir!"

"And how to you come to that conclusion?"

"Well, it's so *clean*!"

"It's certainly uncontaminated by security!"

Little Snitch anyone?

[solosaint (699000)]

most powerusers I know use Little Snitch ... its better than the firewall apple includes

Wait a second...

[CompMD (522020)]

I thought it was illegal for Germans to do this kind of investigation now. Is it? I mean, it requires "hacking tools."

All tests were run on localhost

[hbp4c (315334)]

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.

Re:All tests were run on localhost

[juct (549812)]

Yes you are missing something.

I run all tests from a linux machine. Look at the packet dumps. It shows two machines communicating over a network.
Look at the IP address given as an argument to ntpdate -- it is a public IP of an ISP that I queried from our company network.
Look at the quoted logfile entries. All of them show that the tests have been run from external machines.

bye, ju

I am not convinced

[avatar4d (192234)]

This article is a bit fishy in its interpretation. They don't list their expectations vs the results.. They just make assumptions. For instance:

Users who want to raise their security level might choose the option "Block all incoming connections" - in the hope that this really will reject all incoming queries to network services.

Which it appears to do if you look at the quote below. They show a deny in their logs. Seems to work so far.

The initial tests looked promising. The SSH server activated for testing purposes and the primitive demo backdoor could no longer be accessed from outside. The firewall even blocked access to a test server on a UDP port:

Oct 29 11:26:49 Qf98e Firewall[44]: Deny nc data in from 193.99.145.XXX:28524 uid = 0 proto=17

However, a simple port scan was enough to destroy our misplaced optimism:

# nmap -sU 192.168.69.21
PORT STATE SERVICE
123/udp open|filtered ntp
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
631/udp open|filtered unknown
5353/udp open|filtered zeroconf
MAC Address: 00:17:F2:DF:CD:B3 (Apple Computer)

They are now basing an assumption (or marketing spin) because of output from an Nmap scan. This just indicates a flaw in the signature Nmap has (or the lack thereof) for this particular firewall implementation.

Then straight from NMAP's documentation:

"Nmap reports the state combinations open|filtered and closed|filtered when it cannot determine which of the two states describe a port." -(http://insecure.org/nmap/man/ [insecure.org])

And as for the NTP response being received, well that goes back to what we should expect to see. Apple is about usability. I would suspect that "Block all INCOMING connections" to not refuse information that I request. Basically this just does ingress filtering and not egress.

I haven't read the entire article yet, but from my brief scan I don't see how this is not a "functioning" firewall.

Misleading descriptions

[Todd Knarr (15451)]

I notice in their report that they complain about services Nmap lists as "open/filtered". Nmap reports that result when it encounters a port that elicits no reply whatsoever to a probe. This happens only when a firewall is dropping all traffic to a port and not generating any ICMP error packet for the attempt. The TCP spec says if a port isn't open the client should get an ICMP error, so Nmap knows that there's something there even if access to it's being blocked. If this is any indication of the quality of this "analysis", we can discount the article.

Re:Investigation flawed, more like

[Sloppy (14984)]

so if Leopard trusts the service .. it will have access through the firewall.

The default configuration represents the situation where the user defers to Leopard's estimation of what can be trusted. If the user starts modifying the configuration, then the question of what Leopard trusts or doesn't trust, should be irrelevant.

But sure: they documented the bug, thereby causing it to be merely lame design, rather than a bug.

Re:Investigation flawed, more like

[kebes (861706)]

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.

Re:Investigation flawed, more like

[gatekeep (122108)]

Simply disallowing all incoming UDP traffick is trivially easy ... and doesn't break all that much.

Sure, if DNS isn't 'all that much'

Disallow all incoming UDP/53 traffic, and you'll lose the ability to resolve names. More secure? Maybe. Practical? Absolutely not.

Re:Investigation flawed, more like

[Cally (10873)]

you could argue that reading the documentation for a new firewall would be a useful thing to do as well.

Er, yeah, but... these are Mac users you're talking about. The people who've been sold a computer that ordinary people can use without being computer experts, and which doesn't get viruses like Windows does. (Not counting the Linux refugees, of course.)

Re:Investigation flawed, more like

[Kadin2048 (468275)]

I'm not 100% sure on this, but if it uses the same certificate framework that's been present in OS X up until now (which I can't see why it wouldn't, honestly), it will mean having the CA for the signing certificate in as a trusted root. I assume Apple will have its own CA cert in there by default, but there will probably be a way that users can add other certificates as they see fit. I doubt this will be easy to do, because you don't want idiots doing it because it's easy to do and basically trojaning their own systems (e.g. "To install BigBoobsPorn.app, first download xyz.p12, and install it in your X509Anchors keyring..."), but I suspect that there's no technical reason why you can't do this.

That said, according to what I've read from some people, the security might not even be that rigorous; it might be more about making sure that only the developer of an application can update it automatically (so it's more difficult for an attacker to create an update that 'fixes' your copy of Mail.app or some other approved program to do evil things) than making sure each developer has been vetted by Apple or some other Higher Authority.

There is a posting from someone who supposedly has access to the Leopard previews over at ThinkMac basically saying this:

I can't tell you much without (totally) violating my WWDC NDA, but suffice it to say that this is not as bad as you think it is.

Anyone at all can easily make a new signing identity and use it to sign an application they just compiled.

The main objective of code signing in Leopard is not the same as for SSL certificates -- it is not to evaluate the trust or confidence of something based on a list of trusted certificate authorities.

Rather, it is to provide a much better means for users to identify applications. A good example is software updates. Right now, if a user updates your application, and your application asks for an item the user's keychain, the user will get a Keychain warning telling him the application has changed.

With code signing, the user will get that dialog once the first time he or she runs your application, and if you sign every future versions of that application, the system will not bother the user again, because instead of using for example a hash of the application, it will now be using the code signature.

(source [thinkmac.co.uk])

Re:Investigation flawed, more like

[venicebeach (702856)]

"All applications shipped with Leopard are signed by Apple, and third-party software developers can also sign their applications."

Re:As any new OS

[croddy (659025)]

"Defective by design" is not typically used to refer to "any defective technology, har har", except by a few folks here on Slashdot. "Defective by Design" is a campaign of the FSF, referring specifically devices or software that are deliberately crippled with DRM. see defectivebydesign.org [defectivebydesign.org].

Re:A hardware firewall explained

[by Anonymous Coward]

Actually, no, the literal definition of a firewall is a wall built to block the spread of fire, like the wall between the engine and passenger sections of a car. Not a wall made of fire, lol.