Attacks/Breaches
10/31/2007
07:26 AM
Connect Directly
RSS
E-Mail
50%
50%

Hole-y Leopard!

A first-hand look at the problems with the new OS X OS's firewall

3:26 PM -- I did a fresh install of Mac OS X Leopard the other night. I was looking forward to all of the new features, most of which I didn't even know about. I like running the latest and greatest versions, so Leopard seemed like a good fit.

Apple had been advertising how much more secure Leopard was (cue Kanye West's song "Stronger" but with Leopard being "harder, better, faster, stronger"), but within days of its release, security researchers were already picking it apart. I've always been happy with the firewalling within Mac OS X, using ipfw. The firewall GUI has always been lackluster, but manual configuration is easy because of ipfw's simplified rule language (See Leopard With Chinks in Its Armour.)

But researchers say Leopard's firewall is full of holes. (If you were near my office yesterday, you would have heard me yelling about how their test must be flawed.) So, like other claims against something I like, I recreated the test myself. I set up an old laptop with Xubuntu and connected it to my Mac Book Pro with a crossover cable. After setting up the IPs and confirming they could ping and SSH into each other, I set forth to prove the claims wrong.

But it turns out they were right. The "set access for specific services and applications" firewall setting might as well be the "allow all incoming connections" default. If you thought setting this parameter and allowing SSH would only permit TCP port 22 inbound, you're wrong (as was I). In his test, Jürgen Schmidt used netcat to listen on a local port, and the firewall opened up to allow access to that port. When the firewall setting was changed to "block all incoming connections," access to the netcat listener was blocked. But how many people want to enable SSH, Web sharing, Bonjour, or Remote Desktop on their Leopard machines?

The firewall settings do nothing for UDP. Even at "block all incoming connections," I was able to connect from my Xubuntu laptop to the NTP daemon (ntpd) on my Leopard laptop. I still haven't figured out why Leopard has an NTP daemon accepting connections, but the fact that it is accessible even when all incoming connections are supposed to be blocked is more disturbing.

The firewall logs used to be stored in "/var/log/ipfw.log" in Tiger (Mac OS X 10.4), but are now stored in "/var/log/appfirewall.log." I guess this change is because the Leopard firewall has been enhanced to be application-aware, which is why it opened up to the netcat listener. The other big change is the rules are no longer visible by running "sudo ipfw list." The only rule listed by ipfw when "block all incoming connections" is set is "65535 allow ip from any to any." That's essentially an anti-firewall rule: It does nothing. Or in other words, it allows everything.

There is hope, though. WaterRoof is a GUI frontend to ipfw for Mac OS X and it works well with Leopard. The only issue I've found is that it still expects the logs to be in "/var/log/ipfw.log," so clicking on the view logs button comes up empty. For those of you squeamish about configuring the firewall, the pre-configured rule sets are solid and will work for you out of the box. Just tune the Leopard firewall setting to "allow all incoming connections" and manage everything with WaterRoof. You will have to build your own UDP firewall rules, because there are none included by default. UDP rules tend to get sticky, so at a minimum, deny inbound UDP for ports 123, 5353, and 5454 to cover possible vulnerabilities in NTP and Bonjour.

Even though the firewall may have been flawed to begin with in Leopard, I'm confident that I'm well-protected from network-based threats, using my custom rules. If you're thinking about upgrading, heed the warnings about Leopard's firewall: It's not on by default, and even at its most restrictive setting, it still lets in UDP, and the daemons listening on UDP ports may be vulnerable.

– John H. Sawyer is a security geek on the IT Security Team at the University of Florida. He enjoys taking long war walks on the beach and riding pwnies. When he's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2010-5110
Published: 2014-08-29
DCTStream.cc in Poppler before 0.13.3 allows remote attackers to cause a denial of service (crash) via a crafted PDF file.

CVE-2012-1503
Published: 2014-08-29
Cross-site scripting (XSS) vulnerability in Six Apart (formerly Six Apart KK) Movable Type (MT) Pro 5.13 allows remote attackers to inject arbitrary web script or HTML via the comment section.

CVE-2013-5467
Published: 2014-08-29
Monitoring Agent for UNIX Logs 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP09, and 6.2.3 through FP04 and Monitoring Server (ms) and Shared Libraries (ax) 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP08, 6.2.3 through FP01, and 6.3.0 through FP01 in IBM Tivoli Monitoring (ITM)...

CVE-2014-0600
Published: 2014-08-29
FileUploadServlet in the Administration service in Novell GroupWise 2014 before SP1 allows remote attackers to read or write to arbitrary files via the poLibMaintenanceFileSave parameter, aka ZDI-CAN-2287.

CVE-2014-0888
Published: 2014-08-29
IBM Worklight Foundation 5.x and 6.x before 6.2.0.0, as used in Worklight and Mobile Foundation, allows remote authenticated users to bypass the application-authenticity feature via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.