public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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)?

      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