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.
As soon as the user open the root directory listing, nothing appends but an ask for waiting. But as he/she waits the content of the ꜱᴅ card to show up /var/log starts to fill the whole encrypted partition which is the same as home directories.

A first looks, this looks to be a denial of service, except if we consider that the user who don’t known what command line interface is will quickly follow the official documentation https://www.chromium.org/chromium-os/poking-around-your-chrome-os-device#TOC-Putting-your-Chrome-OS-Device-into-Developer-Mode which states that disabling rootꜰꜱ verification is required to put the device in developper mode which would leverage other file systems vulnerabilities for installing a persistence exploit by simply not dealing with rootfs verification (if rootfs verification no longer works after being turned back on, the user would ignore it and turn it off again). 

VULNERABILITY DETAILS
It seemsrc = read_entries(ef, parent, &entry, 1, *offset); in libexfat in node.c fetch the current entry filling that /var/log/message

The vulnerability is fixed upstream, see the patch

VERSION
All versions starting since R26

REPRODUCTION CASE
For partical purposes, I didn’t put the problem inside the root directory, so just open '/..R' and wait the directory to show up.


 

Deleted: chromiumos-overlay.patch 3.8 KB

chromiumos-overlay.patch 3.8 KB Download

Deleted: ᴀᴍᴅ⁶⁴ ᴘᴏᴄ for Chrome ᴏꜱ 77.0 KB

ᴀᴍᴅ⁶⁴ ᴘᴏᴄ for Chrome ᴏꜱ 77.0 KB View Download