The reaction of the Apple faithful to the disclosure of a security hole in the design of Apple OSX was amazing. A couple of guys figured out that you could trick OSX into executing some foreign code with root privilege by sending a malformed packet to a third-party wireless LAN card. The guys – David Maynor and Johnny Ellch – have been viciously attacked by the Kool-Aid drinking Apple faithful:
I was absolutely shocked when I ran across these stories on Digg. I had personally video interviewed Maynor and his partner Jon “Johnny Cache” Ellch and these two gentlemen were very honest and straightforward. But as soon as I read the stories, the stench began to rise. Maynor and SecureWorks had been telling the truth the entire time and they had falsified nothing. The only falsification going on was the stories themselves! Not only did Dalrymple and Chartier and others like them not follow the most basic of journalism principles to at least check with the source, they apparently didn’t even bother looking at the original video of David Manor released by SecureWorks.
The Faithful claim Maynor and Ellch alleged something they didn’t allege, and are therefore out to get Apple.
The saga continues on George Ou’s ZDNet blog today. It seems to me that the flaw the dudes found depends on bad behavior from both the driver and the OS, and if it exists on one vendor’s product, it certainly can exist on others as well. So Apple and its faithful should simply fix the problem and stop smearing people.
Is that too much to ask?
Except the problem doesn’t seem to exist on Apple’s drivers or Apple’s hardware at all, so Apple can’t fix anything. (Note that Mogull, in the second link, is more or less on Maynor and Ellch’s side, in that he thinks they really did exploit a real bug in real hardware… but he also says they really did exploit it only on third-party hardware and drivers.)
After all, it’s no shock at all to find that third party hardware, with third party drivers, can get you an exploit.
Even the “fanboys” (keep scrolling!) are right sometimes, like in this case.
(Plus Ou really doesn’t impress me with his “my friend’s a legal guy so, uh, somehow that makes my case stronger, and Gruber’s mean!”)
And who has Apple smeared, exactly, when? Nothing I’ve seen from Apple (ie Krebs’ quotes from their PR person) has made anything that could come close to a “smear” against anyone.
I’m sure various fanboys have said things that might be considered smears, but there’s that “Apple and” before “its faithful”… and no good evidence of anything for Apple to fix.)
It seems to me that the vulnerability is at least in part the fault of Apple’s OS, in that it’s allowing drivers a level of access to the system that they shouldn’t have.
I also didn’t see where Maynor and Ellch claimed they’d seen it on any but third-party drivers, and Apple did announce a fix of some sort.
http://blogs.zdnet.com/Ou/?p=305
Clarification on the Atheros issue and why they didn’t get contacted by SecureWorks.
Other issue is that when someone says “driver”, it doesn’t necessarily mean low-level vendor-specific drivers. Driver also can refer to the high-level driver that sits as the interface between the vendor drivers and the OS. FreeBSD had a critical vulnerability in the high-level driver inside the FreeBSD “userland” space which affects all wireless drivers from any vendor. Apple MacBook Pro was released days before the FreeBSD disclosure in January and incorporated those faulty drivers. Since that time, Apple has never publicly acknowledged in an advisory that they have incorporated this FreeBSD driver patch. Now whether or not that vulnerability affects the Mac OS hasn’t been divulged yet but any unpatched issue in the FreeBSD userland is the first place hackers and researchers will look at for vulnerabilities in Mac OS X. Apple PR Lynn Fox has stated they don’t believe they’re vulnerable and hinted Maynor and SecureWorks notified them of this problem. I haven’t been given any more details on this issue.
“I also didn’t see where Maynor and Ellch claimed they’d seen it on any but third-party drivers”
So what? I don’t claim things all the time; so now everything I don’t claim is plausibly true? They admitted that they needed the third-party Atheros driver to perform the exploit. So far, that’s pretty much all we know. Implying otherwise is just spreading the FUD.
Get your facts right Daniel Cottone:
“They admitted that they needed the third-party Atheros driver to perform the exploit.”
No one ever said Atheros drivers were at fault. Atheros doesn’t even write Mac drivers nor do they write FreeBSD or Linux drivers.
http://blogs.zdnet.com/Ou/?p=305
Pardon me: third-party Atheros _card_ driver.
In any event, you are all making assumptions that you are unqualified to make at this point in time in regards to the level of vulnerability in Macs. None of us have seen the source code, nor do any of us know how the exploit works.
Here’s a little nugget I missed:
“It seems to me that the vulnerability is at least in part the fault of Apple’s OS, in that it’s allowing drivers a level of access to the system that they shouldn’t have.”
Oh really? It seems to me that any process that is exploitable inherently grants the exploiter privileges at least equal to the user that ran it. In this case, a driver which is exploitable would grant the exploiter system level privileges. So no, it’s probably not Apple’s fault. At what point do you stop blaming Apple and start blaming third-party software and stupid users?
From what I’m heard about this exploit, there’s a weakness on the way Apple OS maps memory segments and assigns privileges. Data buffers used by WLAN drivers shouldn’t have execute privileges, and certainly not execute privileges as root.
That’s the kernel of the problem, so to speak.
Got any sources for that?
Try reading the PPC or Intel CPU programmer’s reference.
I was talking about a source for the supposed weakness with the way OS X maps memory segments. Got a source for that? Or some personal research?
Or how about anything besides guessing?
This was described in the original Maynor and Ellch revelation, and it’s also programmer’s common sense. How else can you exectute code that comes into a system in a data packet? Most systems are hardened against this kind of attack by the way they setup segment privileges. Code segments are read-only and executable, data segments are read-write and non-executable.
There’s clearly a design flaw in Apple OS. Now it can be tricky to persuade a driver to execute code from a data buffer, but even if you can do that, the OS should not allow it. All competant device driver and kernel programmers know this, Daniel.
So, in actuality you are making a counter claim to David Maynor, since in his video he claims that the exploit and design flaw is not in OS X, but is in the device driver itself:
http://news.com.com/1606-2_3-6101573.html?tag=ne.vid
“The thing to keep in mind here is although we attacked an Apple, the flaw is not specifically in the Apple operating system”
It’s much more probable that Maynor and Ellch figured out a way to get around the memory protection for that specific driver, and there are other ways to implement memory protection besides segmentation.
Again, you know virtually nothing about the exploit; Maynor knows virtually everything about it. He says it has nothing to do with OS X. I’ll take his word for it until I see some proof otherwise.
Based on your knowledge of operating systems, you say: “It’s much more probable that Maynor and Ellch figured out a way to get around the memory protection for that specific driver, and there are other ways to implement memory protection besides segmentation.”
What sort of operating system allows code to execute at root privilege from a data buffer?
What exactly are you saying Richard? Are you defending Maynor’s non-existent claims that OS X is vulnerable, or are you claiming it?
The attack they demonstrated was on an OS X system, was it not? Do the math.
That’s a pretty illogical line of reasoning. Just because the attack was against an OS X machine doesn’t mean that the cause of the vulnerability lies with OS X. Maynor said as much, he’s already verified that the vulnerability has nothing to do with OS X itself.
You seem to be the only one championing some sort of vulnerability with OS X; not only that, you have no proof or even any knowledge of how the exploit works.
Read George Ou’s comment upthread, Daniel, and click on this link.
For the record, I use OS X and like Apple (I own 2). I administer large scale networks and countless unix boxen of the Solaris and Linux variety on a daily basis.
Facts:
1) OS X is vulnerable via the driver… It’s not specific to OS X, but it still is a flaw with way the kernel manages the driver. It’s probably
The Apple fan bois rationalizing reminds me of microsoft complaining about this exact same issue, buggy, poorly written drivers are the cause of most MS instability.
2) Windows still has an awful security record compared to OS X, and it’s not simply due to one being more popular than another.
Microsoft doesn’t have this particular vulnerability because it won’t execute code out of a buffer in kernel space, but sure, the MS driver model is seriously flawed from a security standpoint because once you’ve loaded a driver you can do any damn thing you want in an MS system. They’ve taken some steps to correct his for Vista, but some are pretty onerous, like refusing to load a driver that hasn’t been certified.
Open Source OS’s will always be vulnerable to attack because you can study the sources and figure out how to weasel your code into the system.
I believe this is mostly a theoretical proposition. It’s just as easy to reverse engineer MS vulnerabilities based on the patches they release than to analyze code and find vulnerabilities (Which may not crop up until they meet Mr. Compiler.)
It’s like dealing with idiot vendors who put Database credentials in binaries without using something like crypt believing that such “closed” source security prevents people from simply using something like strings to find the info:)
The most common counter argument to this particular theory is compare the Vulnerabilities of Apache with IIS. Apache is more popular and open source, yet IIS has significantly more *serious* security issues.
I would state that both closed and open source don’t have a significant advantage in terms of code security or exploitability. The “thousand eyes” Open Source argument is just as mythical as the Security through obscurity myth.
It’s the development team’s focus on security and that usually pays off more than anything else. Open Source helps keep people honest in this regard.
Still, I’d rather read source than reverse-compiled binary to find holes in a system.
Of course! Think about it for a minute 😉 You need to verify if the thing is secure one way or another… And most EULA’s are written so the vendor cannot be held liable for security defects. Most of the time vendor security is basically “Trust us!”, and that shouldn’t be good enough for anybody.
Realistically, closed source =! protected source, unavailable source, or unguessable source.
For example: Ever notice when OpenSSL releases a vuln notice, and two weeks later Microsoft releases a notice about a suspiciously similar sounding problem?
I’m not suggesting that Microsoft is “stealing the code” from OpenSSL, but closed or not there are not that many ways to be clever when implenting specific functions and it’s pretty common for people to make the same types of misktakes in completely different implementations if they don’t take steps to focus on security from the get go.
Open source is easier on the eyes.. Thats why everyone from Microsoft, Cisco, Sun and Apple uses OS code… It raises the level of education across the industry, including the consumer. Or it at least has that potential.
Please don’t misinterpret this as advocating the Thousand Eyes Myth, which assumes intrinsic superiority because it’s open source. In many respects, it serves as an example of how not to do things:)
In more earthy and practical terms, I just think that most ISP’s couldn’t survive without it =)