Alastair Houghton Debunks LMH MOKB Finding
Thomas Ptacek | November 30th, 2006 | Filed Under: Apple, New Findings, Uncategorized
Alastair Houghton, past Matasano sniping target, on LMH’s DMG finding:
Because of this, on the second pass through this loop, vm_fault() gets called with address set to point to a non-aligned address inside the first buffer held by the IODeblocker.
Note that it isn’t possible for it to point outside of this buffer, because the segment length, held in segLen has to be in the range 0x1 ≤ segLen ≤ 0x1ff as it’s set up by the IODeblocker to buffer the misaligned part at the beginning of the read. The buffer itself is larger than that, so there’s no chance of any mischief because the ability of a potential attacker to set the address at which vm_fault() gets called is extremely restricted.
Anyway, it is the call to vm_fault() with a non-aligned address that is causing the kernel panic.
So, what have we learned:
It is not a memory overwrite bug.
It is not exploitable, except in that you can kernel panic a machine if you can persuade a user to double-click a damaged dmg file.
It is not, therefore, possible to use this bug for privilege elevation or to execute arbitrary code in the kernel.
Sometimes you pick on a Mac Zealot and they turn around and kick your ass for it. That’s what happened here. Alastair’s analysis is excellent. Hopefully he’ll do this again for other complicated Mac findings.
I apologize for conflating Alastair with Gruber. =) No, wait, I simply apologize to Alastair. Sorry.
An important takeaway point from this: DMGs are a high-risk feature, and one that OS X has substantially greater exposure to than other operating systems. What we had here was a flaw in the DMG loader code. Compared to the underlying filesystem code that runs when the DMG header itself is valid, the DMG code is simple stuff. Long story short: expect more DMG-style problems to come.
alastair
November 30th, 2006 2:14 pmApology accepted, thank-you. (It wasn’t really necessary; I’m not easily offended.)
anonymous
November 30th, 2006 2:23 pmHere’s the link to Alastair’s post:
http://alastairs-place.net/2006/11/dmg-vulnerability/
Steve Christey
December 6th, 2006 7:41 pmAlastair’s post is a good commentary on the problem of vulnerability information management, and the amount of trust people put into refined information sources. If it took 3 days to verify an issue, it shows how resource-intensive (read: impossible) it would be for an information source to personally verify every single claim out there.
alastair
December 7th, 2006 10:38 amIt’s worth saying that (I think) it would take me less time now to do the same thing again, and I’d expect someone with significant experience inside the Mac OS X kernel (especially IOKit) wouldn’t take so long either.
Histrionic
December 7th, 2006 1:46 pmIs it likely that this will be a problem for WIM disk images on Windows Vista, as well?
Thomas Ptacek
December 7th, 2006 4:29 pmI don’t know enough about them, but I know enough to say this: the right way to do this is to use a fixed format like ISO9660, and the absolute wrong way to do is is to make disk images a metaformat with client-selectable filesystems.
Downloadable disk images and actual disks have radically different requirements; actual disks have to do all sorts of work to handle constant modification and keep coherent state. This is why I think disk images are dumb idea to begin with.
Histrionic
December 7th, 2006 5:24 pmWell, from a system administration perspective, disk image containers have a lot of advantages for different usage scenarios.
That’s not to say that there aren’t risks associated with them—because it looks like there’s evidence that there is or will be—but the risk sounds like it’s just simply much worse when they are traded across the ’net. They’re now being used for general purposes rather than being confined to local computers for specific purposes.
Leave a reply