ATTACK SCENARIO
This kind of vulnerability is best suited for targeting a single person since an exploit can only work on a single vendor firmware, but here’s the steps :
An ꜱᴅ card is dropped on a car park. Preferably a large ꜱᴅ card (1Tb) in it’s vendor plastic and it’s several hundred dollars price on it.
The digitally illiterate user who don’t known what formatting a device or hidden files is, will just delete the family pictures and films he sees the disks that appear in the file manager of chrome ᴏꜱ. Then, the user will use the ꜱᴅ card for his own needs until the day one of the partition containing an exploit chain trigger the persistence exploit.

As chrome ᴏꜱ doesn’t offer partitioning tools, the user won’t delete the partitions that don’t appear (if mount.exfat-fuse crash on startup then the exfat partition doesn’t appear in the file manager but ccros-disk will always automatically mount all partition a device contains anyway, even if there’s more than one hundred)


VULNERABILITY DETAILS
mount.exfat-fuse before https://github.com/relan/exfat/commit/38d5c3a929124fd123675ac576401b7de3570b2f didn’t checked sector and cluster size in the correct order.
In some circumstances, 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb)) in mount.c line 211 can turn into a call to malloc(0) while SECTOR_SIZE(*ef->sb) line 220 return a larger attacker controlled size.
Posix requires malloc(0) to create a unique pointer that can be passed to free() (http://www.unix.com/man-page/POSIX/3posix/malloc/). In practice glibc will create a unique pointer pointing to an allocated area of 12 bytes on 32 bits and 24 bytes on 64 bits.
It’s also worth noting such pointer isn’t randomized relative to the beginning of the heap.

The overwriting of dlmalloc data happens in verify_vbr_checksum() located in mount.c.
The attacker doesn’t have fine grained control over the exact size returned by SECTOR_SIZE(*ef->sb), but pread() can succeed while returning less bytes than requested and thus overwriting less dlmalloc data (mount.exfat-fuse doesn’t check the amount of data returned by pread). This can be achieved by reducing the size of the partition.
The attack in the libc begin when mount.exfat-fuse will complain and try to print an error message. This will call several glibc functions which will call vfprintf which will allocate data and read a damaged heap.

There’s 2 repeating factor that can overcome ᴀꜱʟʀ : the fact that cros-disk will automatically mount filesystems instead of doing it on request in the file manager and the exploits only takes bytes which allows to have more than one hundred partitions on the device which will be all mount attempted. As long as they crash mount.exfat-fuse, they won’t show up in the file manager and the user cannot format them without using command line (provided he/she even knows what command line interface is)


VERSION
I’m not aware of a version or device not affected above 25.0.1364.126 (https://chromium.googlesource.com/chromiumos/platform2/+/af455a08a8de7d88cd9550d2d63c865a7c3fc69f).


REPRODUCTION CASE
I repeatedly tried to run the real Chrome ᴏꜱ, but all my attempts failed. As the size of the libraries used determine partially the organization of the stack and the heap I can’t build successful exploit that would run outside my Debian Linux install. So the only thing I can provide is a ᴘᴏᴄ demontrating a partial or full pointer overwrite with attacker controlled data (it bypass glibc buffer detection algorithm see annotated attachment), so this allow writing to arbitrary address.
In order to run the ᴘᴏᴄ, you can use this command as root under developer mode :
mount.exfat-fuse "ᴀᴍᴅ⁶⁴ ᴘᴏᴄ for Chrome ᴏꜱ" /media/removable/archive

There’s three ways to launch a hidden file script as root which will perform a downgrade to a previously valid version allowing mitigated persistence exploits to work again (take a look at the attachments For obvious reason I can’t put a rootfs in those attachements) :
— The 1ˢᵗ is to call setreuid(0,0) as SECBIT_NOROOT is not set, next call to execve will allow to gain full superuser capabilities. Partitions are mounted with noexec : to overcome this, the executable that will be called is /bin/bash with the path to the downgrade script called .s as argument (it’s important for paths to take as less space as possible in the exploit)

— The 2ⁿd consists to call the mount() system call directly to mount a filesystem containing the binaries of /sbin but with a modified chromeos_shutdown script (since no execve system call is performed while the user is logged in) that will install the downgrade images located in the same directory (it requires the user to withdraw the ꜱᴅ card only after shutting down the computer). As I couldn’t ran Chrome ᴏꜱ, I couldn’t determine if /media/removable folder where unmounted on logoff. So the mount system call needs to use a block device, that is, a partition on the ꜱᴅ card with a filesystem that won’t be mounted by cros-disk. This require a file system type supported by the kernel but not by cros-disk which leave squashfs as the only option. Of course, in that case the file manager propose to erase the device but this can be mitigated by write protecting the partition through the controller located on the ꜱᴅ card.
 

Deleted: ᴀᴍᴅ⁶⁴ ᴘᴏᴄ for Chrome ᴏꜱ 116 bytes

ᴀᴍᴅ⁶⁴ ᴘᴏᴄ for Chrome ᴏꜱ 116 bytes View Download

Deleted: core 508 KB

core 508 KB View Download

Deleted: annotated malloc for arbitrary address write by fetching partially corrupted pointer from heap.c 14.1 KB

annotated malloc for arbitrary address write by fetching partially corrupted pointer from heap.c 14.1 KB View Download

Deleted: second partition containing script data in the case of setresuid(0,0) in the ʀᴏᴘ chain.vfat 64.0 KB

second partition containing script data in the case of setresuid(0,0) in the ʀᴏᴘ chain.vfat 64.0 KB Download

Deleted: partition block device that should be mounted over sbin containing modified chromeos_shutdown script and old firmware.squashfs 2.8 MB

partition block device that should be mounted over sbin containing modified chromeos_shutdown script and old firmware.squashfs 2.8 MB Download

Deleted: chromiumos-overlay.patch 3.8 KB

chromiumos-overlay.patch 3.8 KB Download