[Bug 216283] FUZZ: BUG() triggered in fs/ext4/extent.c:ext4_ext_insert_extent() when mount and operate on crafted image

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216283

--- Comment #10 from Zhang Boyang (zhangboyang.id@gmail.com) ---
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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.