linux-kernel - Malicious fs images was Re: ext4 regression in v5.9-rc2 from e7bfb5c9bb3d on ro fs with overlapped bitmaps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210110184101.GA4625@amd>
Date:   Sun, 10 Jan 2021 19:41:02 +0100
From:   Pavel Machek <pavel@....cz>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Josh Triplett <josh@...htriplett.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-ext4@...r.kernel.org
Subject: Malicious fs images was Re: ext4 regression in v5.9-rc2 from
 e7bfb5c9bb3d on ro fs with overlapped bitmaps

Hi!

On Fri 2020-10-09 10:37:32, Theodore Y. Ts'o wrote:
> On Thu, Oct 08, 2020 at 03:22:59PM -0700, Josh Triplett wrote:
> > 
> > I wasn't trying to make a *new* general principle or policy. I was under
> > the impression that this *was* the policy, because it never occurred to
> > me that it could be otherwise. It seemed like a natural aspect of the
> > kernel/userspace boundary, to the point that the idea of it *not* being
> > part of the kernel's stability guarantees didn't cross my mind. 
> 
> >From our perspective (and Darrick and I discussed this on this week's
> ext4 video conference, so it represents the ext4 and xfs maintainer's
> position) is that the file system format is different.  First, the
> on-disk format is not an ABI, and it is several orders more complex
> than a system call interface.  Second, we make no guarantees about
> what the file system created by malicious tools will do.  For example,
> XFS developers reject bug reports from file system fuzzers, because
> the v5 format has CRC checks, so randomly corrupted file systems won't
> crash the kernel.  Yes, this doesn't protect against maliciously
> created file systems where the attacker makes sure the checksums are
> valid, but only crazy people who think containers are just as secure

Well, it is not just containers. It is also USB sticks. And people who
believe secure boot is good idea and try to protect kernel against
root. And crazy people who encrypt pointers in dmesg. And...

People want to use USB sticks from time to time. And while I
understand XFS is so complex it is unsuitable for such use, I'd still
expect bugs to be fixed there.

I hope VFAT to be safe to mount, because that is very common on USB.

I also hope ext2/3/4 is safe in that regard.

Anyway it would be nice to have documentation explaining this. If I'm
wrong about VFAT being safe, it would be good to know, and I guess
many will be surprised that XFS is using different rules.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)