Apple DMG Security Challenges (DMG Control)
Tom’s recent post on filesystem fuzzing. Mentions Apple filesystems being downloaded and mountable. I wanted to spend a little more time talking about DMGs. DMGs are Apple’s version of a filesystem contained in a file. They are useful for a number of things, but OS X users probably see them most often as a way of downloading and installing software. What is interesting about DMGs is that they allow non-privileged users to mount a filesystem. This poses a number of unique threats to OS X.
The first one is getting a lot of discussion right now. DMGs opens up an attack vector into the kernel that is far less common in other operating systems. Eventually, when a user mounts a DMG (typically done by just double clicking on it), the kernel will be involved in interacting with the filesystem. Since this filesystem can be created by an attacker and delivered remotely (via a web browser download) or created by a local non-privileged user, attackers have the ability to find kernel based vulnerabilities through filesystem code paths inside of the kernel. While I am oversimplifying this a little, the end result is that it may be possible for an attacker to remotely exploit a kernel buffer overflow in the filesystem code (should it exist). DMGs support the following filesystem types: HFS+, HFS+J, HFSX, HFS, MS-DOS, or UFS. Thats a pretty large attack surface.
A second issue that arrises from user control of the mounting of user defined filesystems (just typing that made me twitch) is that the security model of filesystems can be drastically different. For example, while HFS+ has something called ‘file permissions’, MS-DOS does not. And even if that werent the case, all of the files written to a DMG mounted filesystem ultimately end up inside of a file that an attacker will be able to read from. This opens up some unique exploitation techniques for Mac OS X local file vulnerabilities. I actually talked about this in 2003. Essentiallly, anytime you can coax a file containing sensitive information to be written to your filesystem, it is yours, regardless of file permissions/ownership. While there have always been techniques to do this (e.g. FIFOs), this makes it even easier.
6 Comments so far
Leave a reply
It isn’t as dead simple as fs fuzzing, but there was actually a paper well worth reading about filesystem bugs at this year’s IEEE Security and Privacy:
Automatically Generating Malicious Disks using Symbolic Execution
Junfeng Yang, Can Sar, Paul Twohey, Cristian Cadar, and Dawson Engler
http://metacomp.stanford.edu/~twohey/papers/ieee2006-symbolic-disks.pdf
Summary: SAT solver finds disk images of death!
Seriously, the paper’s worth a read. If nothing else, it suggests something to do if we ever get fs code to the point where it doesn’t fall over and die once you yell “/dev/urandom” at it…
Sorry, I’m definitely missing something here.
How does the attacker read from the DMG?
It’s very well to say “anytime you can coax a file containing sensitive information to be written to your filesystem”, but once the DMG is downloaded, the filesystem belongs to the user, not the attacker.
Ceri:
The second half of my post has to do with local privilege escalation attacks, which assumes a hostile user with a shell account on an OSX machine.
Sorry, of course; I missed the word “local” in there.
Well, well, well! It’s a corrupted UDRW (read/write) disk image!
Why should that matter? Because the disk image mounter doesn’t get to do a checksum before the mount.
If this was a read-only disk image, the disk image mounter would have checked for a checksum first before trying to mount it… and because it fails the checksum test:
$ hdiutil verify /Users/tonza/Desktop/MOKB-20-11-2006.dmg
hdiutil: verify: “/Users/tonza/Desktop/MOKB-20-11-2006.dmg” has no checksum.
$ _
then the mounter would have rejected the mount request.
The problem here is that Safari is allowing read-write disk image mounts to occur. This is bad, because the disk image is never verified for integrity! While I believe that mounting a disk read/write on your system is always owner’s onus should a kernel panic occur (you can cause your own panics when disk corruption by improper flushing occurs anyway), mounting a disk image read-only should be much more stringent. Safari should be fixed to:
1) only attempt to automatically mount read-only disk images if the user elects to do so, and
2) ensure that the hard disk image file is verified before being mounted.
My take on the matter? Ditch Safari for another browser instead!!! This is not a kernel failure per-se… this is a stupid Safari bug for trusting an untrusted source in the first place.
I am not so sure the checksum thing would work here. I am going to guess that the DMG was created, then corrupted using a fuzzer. I would assume that the checksum could have been recalculated and wasnt.
I think the problem here is bigger. DMGs are a remote risk, but they also pose several risks in multi user environments.