On 4/29/26 00:40, Theodore Tso wrote:
> On Tue, Apr 28, 2026 at 04:50:14PM -0400, Demi Marie Obenour wrote:
>> This is an example of a BadUSB attack, which has been known since
>> at least 2014.  USB sticks *do* have their own microcontrollers to
>> run their firmware.  At least in the past this firmware has been
>> programmable and not been digitally signed.  This means that the USB
>> stick *can* be reprogrammed to perform a TOCTOU attack on a filesystem,
>> or indeed to implement a completely different kind of USB device.
> 
> Honestly, if that's what you are worried about, then best solution is
> put epoxy in every single USB port.  I've since financial institutions
> that have done precisely this, and both Android and Chrome OS supports
> enterprise security policies which does the equivalent in software.

That works well in enterprises using laptops, tablets, or mobile
devices.  Enterprises can require that all devices have built-in,
non-USB input devices or touchscreens.  Furthermore, corporate
environments use network-based backup and file sharing.  So there
is hardly a need for USB except for security tokens, smart card
readers, OS installation media, and miscellaneous hardware devices
that generally will not be hotplugged.  Only the third is a block
device, it is trusted, and it can be a USB stick with a physical
write-protect switch and signed firmware.

>> Protecting against replay attacks requires a Merkle tree.  The only
>> Linux filesystems that I know have one are ZFS, bcachefs, and BTRFS.
>> The first two are out of tree and the third is not shipped in RHEL
>> at least.
> 
> FYI, there was a patch for btrfs, but it was never landed.  It's
> unclear how many people would be willing to pay the performance tax of
> using hmac-sha256 for every single data and metadata block write.   

I thought BTRFS already had one.  In any case corrupting an encrypted
disk will cause a checksum failure with fairly high probability,
as a 128-bit region is completely scrambled.

>> Of course, you are free to choose which (if any) of these attacks you
>> care about.  One can that USB sticks should be mounted in userspace,
>> UEFI secure boot with Microsoft keys is irrelevant as long as
>> administrator -> kernel isn't a security boundary on Windows, and that
>> confidential computing only makes sense for stateless workloads (which
>> can use dm-verity) until there is a way to trust storage devices.
>> But it's always best to be aware that an attack vector exists,
>> whether or not one chooses to address it.
> 
> Sure, but a drive-by comment on a patch review advocating that we slow
> down ext4 to protect a single instance where the attacker has
> read/write access to a mounted block device, when the file system
> doesn't have generalized protections against that whole class of
> attacks.... isn't particularly helpful.

My main goal is to point out that the attack vector does exist.
If nothing else, hopefully this will persuade distro maintainers
to switch to using libguestfs + FUSE as the default way to mount
USB drives.  That isolates the driver in a VM.

Qubes OS users can already mount the device in a disposable VM,
and presumably many of them already do that.  Again, this provides
strong isolation and severely limits the impact of an exploit.

I do wonder if this could be used against confidential computing
workloads.  That said, work there would more likely be put into
allowing them to attest their storage.

> By the way, I'm not aware of *any* company that has been interested in
> funding work to protect against this class of attacks.  Given that
> most file system developers prefer food with their meals, and have
> enough *other* unfunded mandates from our user community, it doesn't
> seem likely that we're going to see much forward progress towards your
> desires/interests.
I'm not surprised at all.

The people who would benefit the most from this work are consumers
who are running desktop Linux on general purpose computers they own.
I have spent most of my career providing secure solutions for these
people.  I worked on Qubes OS for several years, and I now work
on Spectrum.

Unfortunately, this group has very little budget and so very little
market power.  Therefore, work that benefits them is perpetually
and massively underfunded.  Grants do exist, and crowdfunding might
also be an option.  However, unless one is very passionate about the
client space, it is hard to resist much better-paying jobs in the
server world.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)