Slashdot Mirror
Amit Singh's Challenge: Find a Decade-Old Bug
dreicodan writes "Well this has too many juicy Mac OS X nuggets in one bag! All details are on this page, but I'll summarise. Apparently Amit Singh discovered a 10+ year old serious bug in OS X. The bug started in Nextstep and is still in Panther (and apparently Tiger, too). Then Amit wrote a program to demo the bug, but also made the program capable of hiding what it does using some complicated Mach kernel voodo! He then threw a challenge open to OS X experts to figure out the bug. It turns out that a week and some 1000 downloads later, three brilliant hackers (Alexy Proskuryakov, Andrew Wellington, Graham Dennis) were able to solve the puzzle. Also looks like other than these guys, nobody got anywhere with the problem. Be ready for extremely gory details of how the program was written and how it was decoded. Its a thrilling read, and OS X hacking doesn't get any more hardcore than this! Hopefully Apple fixes this bug now at last."
I agree. Either they didn't know it was there, or they didn't think it was important enough to fix right away.
But that's different from them not knowing how to fix something, which I'm sure they do.
Everything I need to know about copyrights I learned from Slashdot.
NS had a lot of old bugs due to its use of 4.2BSD. People would report it but hardly any would get fixed/patched/updated. So I would not be surprised if some of these bugs were not purged by OS X's use of a more up-to-date version of BSD and its subsequent kernel reorg.
Would you care to submit an example of a similar or worse M$ (note clever use of $) bug that they couldn't find or fix for 10 years?
Does c:\con\con count?
Excessive forking causes un-wanted children.
"Could you at least of provided a simple Cocoa GUI for your program? Terminal app programs are not very popular with Mac people, you know."
that's the response I got when macupdate.com had automatically picked up one of my sf.net projects. I made an OSX installer package for my binaries and received many complaints about it in the "discuss this software" forum of macupdate...
bastards.
...spike
Ewwwwww, coconut...
with the Russians Claim Their Hackers the Best In the World Article - Winner is a Russian ;-)
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
Yup, I submitted it too ... twice. Once on the day this was announced, and another a couple days later when a fixed deadline was announced. Challenge still had 5 days to go. Rejected both times. I think OS X people don't want to hurt their heads thinking about bugs and hacking and system level things :)
Given that the bug wouldn't be too hard to fix, and is a serious bug, I doubt that that is the case. On the contrary, while it is a bit annoying that this sort of oversight in the kernel design does exist, I think it speaks well for NeXT and Apple that they have not discovered it in all this time.
:-) can pop up. Now, the fact that OS X has a sort of Mach/BSD - Jekyll/Hyde sort of thing going on in the kernel means that you should expect it to be very tempting for many developers to haphazardly make system calls as they see fit. But if that had been the way development worked at NeXT, you can bet your pants that this bug would have been discovered at least a decade ago. (Mr. Singh doesn't say exactly how far this thing goes back, but I'm going to guess it has been in NEXTSTEP the entire time - about two decades.)
NEXTSTEP/OS X has an incredibly layered architecture, and those layers are quite well-stratified. That stratification is a great design asset - it makes it a lot easier to keep the whole mess organized, and reduces the number of boundary conditions where bugs (such as this kernel bug
-BUT-, the bug is still there. While I normally hate old bugs as much as anyone, especially ones that cause kernel panics, in this case I am sincerely and profundly impressed at the amount of discipline that must have been present in the development culture at NeXT. (We'll see about Apple - on the inside, Classic MacOS became quite possibly the most tangled kludge of an operating system ever produced in its last few incarnations, and I do get the impression that Apple is starting to take OS X down that path, too.)
This was this myth I heard from someone at MIT, no I didn't go there....
There was an old terminal machine from the 70s that had a weird bug of permanently hiding processes far beneath "ps" so no admin could ever see it. When the machine was decommissioned in the 90s, the shutdown revealed some student's print-paper-lpr process that got lost for 20 years.
"There are millions of lines of source code in any modern operating system. Exploits don't sprout overnight like mana from heaven. The most useful skill for divining exploits is to notice the existence of edge cases in how various subsystems interact with one another."
Indeed. I think the problem is not that nobody was looking for flaws, but that they were looking in the parts they're familiar with. They'd be looking in the BSD-oriented parts, or the upper levels of the OS.
They probably wouldn't be looking in the Mach parts of the OS, where this bug appears. I doubt many people have spent the time to learn enough about Mach to think of potential exploits.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
People in Capital One, Compound Therapeutics, Fossil, Goldman Sachs, IKEA, and SAAB were interested enough to download this, but no one from the Semantecs/Sophos/Secunas of this world found it worth their while to check it out??!!
I would certainly hope that they are paying attention to the use of dynamic code modification, code obfuscation, and red herrings. While these techniques are not new, none of the (Windows) malware seen so far were designed to be even half as proficient in these matters as panpipes. Further, Amit has stated that he could have made panpipes even more difficult to debug (but didn't).
Kudos to Amit for this highly educational exercise! He certainly seems to know his way about the innards of OS X (not to mention all the other OSes he runs on his 17"PB via VPC.)
(I bet he has some interesting insights about the evolution and workings of OSes from MS (he is running ALL the flavors of DOS and Windows that I know of.)
If that's the only example like that which can cause a kernel panic, I'd be impressed. Especially in kernel-level I/O areas where performance is key, it's even possible that such a check is left out on purpose, and data integrity is meant to be the job of some higher-level or intermediary calling function which is ( nearly ) always used.
Of course, I avoid programming on such a low level if possible, so I could be wrong. But it is likely there's a reason why fixing this isn't terribly important, and why my OS X machine *never* reboots unless I've done some system software update.