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."
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...
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
And, FWIW, if I set the firewall to 'Set Access for specific services and applications', then disable SMB sharing, I can't connect using nmblookup. I can only get through when the service has been enabled (which seems reasonable).
Simon
Physicists get Hadrons!
As any new OS out there, these are childre diseases. Every new system will have problems: small problems and big problesm. The difference is that some will get praise anyway and some others will get "defectivebydesign" or "haha" tags.
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
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 ----
I guess we should expect to see 10.5.1 pretty soon.
"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!"
most powerusers I know use Little Snitch ... its better than the firewall apple includes
This was pointed out on a previous slashdot article and this poster claims it is not true.
Tagging this "defectivebydesign" doesn't make any sense here at all, whether or not Apple's a monopoly. "Defective by design" is a phrase coined to describe DRM encumbered products, because they really are designed to be that way. A defect in a firewall is most definitely not intentional. Unfortunately, "defective by design" has lost its roots, and has become a phrase that is mindlessly repeated by the slashdot hoards whenever any product has any problem with it whatsoever. Obviously it couldn't be due to oversight or incompetence, Apple must have intentionally gone out of their way to make a flaw in their firewall because they're evil. /sarcasm
I thought it was illegal for Germans to do this kind of investigation now. Is it? I mean, it requires "hacking tools."
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.
Which it appears to do if you look at the quote below. They show a deny in their logs. Seems to work so far.
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/)
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.
Confucius say: "Man who associates with smarter men than himself is smarter than the men he associates with."
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.
[Rant]
There is no such thing as a purely hardware firewall in modern times.
The hardware like a Cisco pix has software (i.e. firmware) running on top of a simple (usually Linux or bsd architecture). A true hardware firewall is John or Jane sitting at a switchboard plugging in and unplugging cables, like way back when telephones first existed. You could also theoretically unplug the networking cable every-so-often to get a firewall-like effect, but the bottom line is that there is something (a brain) that decides what goes in and what goes out. The brain is a bunch of code (software) that is the firewall.
Hell, create a searing flame capable of burning anyone to death who dare walks through it- that's the literal definition of a firewall. The heat caused by the burning of wood or something else is a "hardware" firewall.
[/Rant]
Why isn't this story also tagged as "haha"?
If this was a story about a Windows Firewall, as well as defectivebydesign you'd also have the "haha" tag. Do I detect bias?
... so 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 - if Jo(e)-evil-cracker already has 'root' on the system, the firewall isn't going to help save the system, after all... Perhaps Heise are just used to using Linux, where the firewall trumps all ? And what happens in the event the trust system is subverted somehow? Either the user accidentally trusts malware, or malware manages to squeeze itself in, what would the user do? The only option they have left is to pull the network connection. At least with a real firewall, a savvy user can lock down their machine and safely investigate further. 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. I thought the appeal of Apple was that Things Just Work and it is so intuitive you don't have read the documentation? This is a major bug. Don't try to downplay it like its no big deal. Security is always a big deal. I thought we all learned that from the countless Windows worms?Firewalls are half-assed anyway, why bother with half-assed security, never do it halfway... I say go full-assed and leave all ports open! Take back the internet! Let our data flow! Freedom! DISCLAIMER: I don't know shit about security, as a result I don't keep any sensitive info on my computer.
Out in hall, wasn't it? No, don't get up...
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
I'm sitting here on my Macbook sharing my 3G connection from my phone over WiFi to a few of my coworkers' laptops, and Apache is certainly not running. Currently I'm on 10.5, but I never had to turn it on with 10.4 either.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
No. It means that the firewall's black-holing (dropping without generating any ICMP response) all packets to ports 80 and 443. It can do this whether or not a Web server's running.
Unlike Windows, OSX does not run with services enabled unless you explicitly enable them.
It sounds like if you don't enable a service, it doesn't enable the firewall rules for that service. If you do enable the service, then it turns on the firewall rules for that service. This is not a problem unless you install a third-party program that provides the same network service, *and* you want to restrict access to it.
The argument in the article that the firewall would prevent a trojan from opening a listener on a low port is bogus, because any program that can open a listener on a low port can also remove the corresponding firewall rule... you have to be root to do either.
The fact that Samba processes were still running after sharing was turned off, however, is a concern. That absolutely should not happen, and Apple needs to fix it.
The workaround is to make sure that after you disable a service, you reboot to make sure it is really disabled. If you don't enable any services that should not be an issue.
http://leofud.blogspot.com/
Specifically that the open|filtered may mean the ports are in a stealth mode... which is what you want!
I did a port scan of my Leopard machine from a Tiger machine and didn't see any open ports at all. I'm not running the firewall either -- but I don't have any services turned on right now. That's the way OS X ships by default (and has since as least 10.2).
Not arguing that things couldn't be better communicated by Apple, but I think an article claiming they're taking a Microsoft-esque tact toward security is more than likely politically loaded.
In OS 10.4 Tiger, in order to block UDP traffic, one had to click on the Advanced tab in the Firewall pane and select "block UDP traffic" otherwise the firewall would only block TCP traffic. If you notice in the article, all the open ports are UDP. I don't have a copy of Leopard yet, but given that the author didn't mention anything about the advanced tab I wouldn't be surprised if it's still the same for Leopard and that he didn't make this selection.
Blocking UDP traffic in 10.4:
http://docs.info.apple.com/article.html?path=Mac/10.4/en/mh1242.html