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