Darwin Nuke the Refrigerator, Wet Sprocket, etc.

Two more security notes.

First, as a followup, a couple of you pointed out that there is a writeconfig on 10.4 through 10.6 (and actually earlier) in /System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources. Yes, there is, and it's even setuid root (I wish Apple wouldn't do that). However, it is not exploitable, at least not by systemsetupusthebomb or a similar notion, because it appears to lack the functionality required for that sort of attack. I should have mentioned this in my prior posting.

Second, Darwin Nuke is now making the rounds, similar to the old WinNuke which plagued early versions of Windows until it was corrected in the Windows 95 days in that you can send a specially crafted packet to an OS X machine and kernel panic it. It's not as easy as WinNuke was, though -- that was as simple as opening a TCP connection to port 139 on the victim machine and sending it nonsense data with the Urgent Pointer flag set in the TCP header. Anyone could do that with a modified Telnet client, for example, and there were many fire-and-forget tools that were even easier. Unless you specifically blocked such connections on ingress, and many home users and quite a few business networks didn't at the time, WinNuke was a great means to ruin someone's day. (I may or may not have done this from my Power Mac 7300 a couple times to kick annoying people off IRC. Maybe.)

Darwin Nuke, on the other hand, requires you to send a specially crafted invalid ICMP packet. This is somewhat harder to trigger remotely as many firewalls and routers will drop this sort of malformed network traffic, so it's more of a threat on an unprotected LAN. Nevertheless, an attacker with a raw socket interface can engineer and transmit such packets, and the technical knowledge required is relatively commonplace.

That said, even on my test network I'm having great difficulty triggering this against the Power Macs; I have not yet been able to do so. It is also not clear if the built-in firewall protects against this attack, though the level at which the attack exists suggests to me it does not. However, the faulty code is indeed in the 10.4 kernel source, so if it's there and in 10.10, it is undoubtedly in 10.5 and 10.6 as well. For that reason, I must conclude that Power Macs are vulnerable. If your hardware (or non-OS X) firewall or router supports it, blocking incoming ICMP will protect you from the very small risk of being hit at the cost of preventing pings and traceroutes into your network (but this is probably what you want anyway).

Even if you do get nailed, the good news (sort of) is that your computer can't be hacked by this method that anyone is aware of; it's a Denial of Service attack, you'll lose your work, you may need to repair the filesystem if it does so at a bad time and that sucks, but it doesn't compromise the machine otherwise. And, because this is in open source kernel code, it should be possible to design a fix and build a new kernel if the problem turns out to be easier to exploit than it appears currently. (Please note I'm not volunteering, at least, not yet.)

So, you can all get out of your fridges now, mmkay?

10.4Fx 38 and IonPower update: 50% of V8 passes and I'm about 20% into the test suite. Right now wrestling with a strange bug with return values in nested calls, but while IonPower progress is slow, it's progress!