From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ingo Molnar <mingo@kernel.org>
Cc: Jann Horn <jannh@google.com>,
andriy.shevchenko@linux.intel.com,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
the arch/x86 maintainers <x86@kernel.org>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/mtrr: don't copy out-of-bounds data in mtrr_write
Date: Mon, 16 Jul 2018 03:26:01 +0100 [thread overview]
Message-ID: <20180716022600.GN30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180715220339.GA15435@gmail.com>
On Mon, Jul 16, 2018 at 12:03:39AM +0200, Ingo Molnar wrote:
>
> * Jann Horn <jannh@google.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.)
*Ugh*
You do realize that there's a lot of magical mystery shite that looks like
regular files? And what's wrong with directories, BTW?
While we are at it, "passed" in which sense? Via SCM_RIGHTS? Those are
only get accepted if recepient explicitly asks for those - simple read()
or recv() will have them quietly discarded, special or not.
And if it's "inherit over execve()"... Your definition *will* break.
Instantly. Right as you try to run su or sudo, with stdin/stdout/stderr
all going to a character device. Terminal, that is.
Frankly, something like
copyin_limited(buf, len, kbuf, size)
and several similar helpers would be a lot more productive than open-coding
these checks over and over or trying to come up with definitions of "special"
that would work.
BTW, what's the point open-coding
if (sscanf(line, "base=%ull size=%ull type=%s", &base, &size, &type) != 3)
return -EINVAL;
if ((base & 0xfff) || (size & 0xfff))
return -EINVAL;
i = match_string(mtrr_strings, MTRR_NUM_TYPES, type);
if (i < 0)
return i;
as
if (strncmp(line, "base=", 5))
return -EINVAL;
base = simple_strtoull(line + 5, &ptr, 0);
ptr = skip_spaces(ptr);
if (strncmp(ptr, "size=", 5))
return -EINVAL;
size = simple_strtoull(ptr + 5, &ptr, 0);
if ((base & 0xfff) || (size & 0xfff))
return -EINVAL;
ptr = skip_spaces(ptr);
if (strncmp(ptr, "type=", 5))
return -EINVAL;
ptr = skip_spaces(ptr + 5);
i = match_string(mtrr_strings, MTRR_NUM_TYPES, ptr);
if (i < 0)
return i;
Saving the copying of 'type' (which we need since '%n' is declared useless)?
prev parent reply other threads:[~2018-07-16 2:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 21:50 [PATCH] x86/mtrr: don't copy out-of-bounds data in mtrr_write Jann Horn
2018-07-07 17:04 ` [tip:x86/urgent] x86/mtrr: Don't " tip-bot for Jann Horn
2018-07-09 6:52 ` [PATCH] x86/mtrr: don't " Andy Shevchenko
2018-07-09 7:41 ` Jann Horn
2018-07-09 8:20 ` Andy Shevchenko
2018-07-15 22:03 ` Ingo Molnar
2018-07-16 1:32 ` Jann Horn
2018-07-16 1:46 ` Linus Torvalds
2018-07-16 2:26 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180716022600.GN30522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox