linux-kernel - Re: [PATCH] x86/mtrr: don't copy out-of-bounds data in mtrr

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180715220339.GA15435@gmail.com>
Date:   Mon, 16 Jul 2018 00:03:39 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Jann Horn <jannh@...gle.com>
Cc:     andriy.shevchenko@...ux.intel.com,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/mtrr: don't copy out-of-bounds data in mtrr_write


* Jann Horn <jannh@...gle.com> wrote:

>  - A malicious user can pass an arbitrary file to a setuid binary as
> stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to
> be something normal, like a proper file or a pipe) then calls read(0,
> <buf>, <len>), if the kernel disregards the length argument and writes
> beyond the end of the buffer, it can corrupt adjacent userspace data,
> potentially allowing a user to escalate their privileges; a write
> handler is somewhat less interesting because it can probably (as in
> this case) only leak out-of-bounds data from the caller, not corrupt
> it, but it's still a concern in theory.

BTW., a naive question: would it make sense to simply disallow 'special'
fds to be passed to setuid binaries, and fix any user-space that breaks?
(i.e. only allow regular files and pipes/sockets.)

Also, don't allow splice() on special files either, except if the driver 
explicitly opts in to it.

Sounds a lot more robust in the long run than playing whack-a-mole with the 
*inevitable* hole in special read() and write() handlers in our 3,000+ device 
drivers...

Thanks,

	Ingo