Hi,
On 2022/8/2 11:25, Dave Chinner wrote:
I don't particularly worry about "responsible disclosure" because I
don't consider fuzzed file system crashes to be a particularly serious
security concern. There are some crazy container folks who think
containers are just as secure(tm) as VM's, and who advocate allowing
untrusted containers to mount arbitrary file system images and expect
that this not cause the "host" OS to crash or get compromised. Those
people are insane(tm), and I don't particularly worry about their use
cases.
They may be "crazy container" use cases, but anything we can do to
make that safer is a good thing.
But if the filesystem crashes or has a bug that can be exploited
during the mount process....
I think filesystem-safety is very import to consumer devices like
computers or smartphones, at least for those filesystems designed for
(or widely used for) data exchange, like fat and exfat. Please see my
comments below.
On the other hand, filesystem designed for internal use like ext4 or xfs
can ignore deliberate manipulation but users still expect they can deal
with random errors, e.g. you don't want whole file server down because
of single faulty disk. And this has nothing to do with containers.
If you have a Linux laptop with an automounter enabled it's possible
that when you plug in a USB stick containing a corrupted file system,
it could cause the system to crash. But that requires physical access
to the machine, and if you have physical access, there is no shortage
of problems you could cause in any case.
Yes, the real issue is that distros automount filesystems with
"noexec,nosuid,nodev". They use these mount options so that the OS
protects against trojanned permissions and binaries on the untrusted
filesystem, thereby preventing most of the vectors an untrusted
filesystem can use to subvert the security of the system without the
user first making an explicit choice to allow the system to run
untrusted code.
But exploiting an automoutner does not require physical access at
all. Anyone who says this is ignoring the elephant in the room:
supply chain attacks.guarantee
All it requires is a supply chain to be subverted somehere, and now
the USB drive that contains the drivers for your special hardware
from a manufacturer you trust (and with manufacturer
trust/anti-tamper seals intact) now powns your machine when you plug
it in.
Did the user do anything wrong? No, not at all. But they could
have a big problem if filesystem developers don't care about
threat models like subverted supply chains and leave the door wide
open even when the user does all the right things...
Yes, an attack need physical access doesn't means the attacker need
physical access.
USB sticks (or more generally, external storage devices), is still a
very important way to exchange data between computers (and/or smart
devices), although it's not as common as before. No safe guarantee here
means there is no way to even read untrusted filesystems without using
virtual machines / DMZ machines. Thus, using untrusted filesystems
natively will become "give root privilege to those who wrote to that
filesystem". That makes me recall the nightmare of autorun.inf worms on
Windows platforms. I think no user/vendor really want this. At least I'm
sure it would be scandal for Tesla if their cars can be hacked by
inserting a USB stick.
Best Regards,
Zhang Boyang
