Yeah, this almost isn't exploitable, if I understand the bug correctly:
- User mounts a filesystem backed by a dmg file.
- Attacker with write permission on the dmg file modifies it.
- Attacker uses a huge amount of RAM so that the in-memory copies of the data from the DMG get pushed out.
- Kernel reads in modified DMG from disk when asked to read blocks from disk.
And in particular, the only definitive impact is when:
- User runs app that sends Mach messages to another app using out-of-band data backed by a file on a DMG.
- Attacker with write permission on the dmg file modifies the DMG.
- Attacker uses a huge amount of RAM so that the in-memory copies of the data from the DMG get pushed out.
- Kernel reads in modified DMG from disk when asked to provide the contents of that Mach message.
The only realistic exploits I can think of are things like:
- Tricking the kernel into reloading a code page from an app running from a DMG after modifying it (very hard to exploit) while the app is running (to get around Gatekeeper)
- Modifying or intercepting Mach messages in flight by mounting a DMG over top of /var/tmp (requires root) or some other location where apps are likely to store this sort of data.
And if you can do the latter, you can probably just use a modified kernel to do the same thing.
I'm really curious why this is considered high severity. At a glance, I would have called it a nuisance-level security bug.
This is actually about modifying things that are temporarily stored on a DMG by modifying the underlying volume. If this were about modifying a DMG to avoid integrity checks, an attacker could just disable the checksum or substitute another volume with a valid checksum. Those checksums are to prevent corruption, not modification. Code signatures, on the other hand....
