lmh had posted not one, but two advisories about dmg related vulnerabilities in Mac OS X.

The first I’ve already dealt with, but since some people had combined the two issues into a single overall advisory, I thought I’d address the second one (CVE-2006-6062) as well.

This is much simpler than the first, which in a way makes it even less excusable to claim memory corruption when it doesn’t exist. However, in this case lmh didn’t claim that it allowed arbitrary code execution or make similar exaggerations. So, what is wrong here?

Well, what he’s done is he’s corrupted the Catalog File, which is a critical piece of filesystem metadata that tells HFS+ where things are on the disk. And the corruption in question means that it can’t find the root folder’s record. So whilst the call to VFS_MOUNT() in the mount() system call will succeed, when checkdirs() is subsequently called and tries to get a vnode for the filesystem root, VFS_ROOT() returns ENOENT, which triggers a kernel panic with the reason “mount: lost mount”.

Interestingly this particular problem is probably specific to HFS+, as most other filesystems wouldn’t be able to lose their root folder so easily.

So again, I don’t see any memory corruption. All you can do is trigger a kernel panic.

Let me be clear though; lmh didn’t claim that this was as serious as the other one. One thing he didn’t mention, however, about this bug (because he didn’t investigate it properly) is that it doesn’t just affect UDTO disk images… this is bug will trigger with suitably corrupted filesystems on any type of media, which could be annoying for an end user if it happens on their hard disk.