[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161220092734.GA12200@kroah.com>
Date: Tue, 20 Dec 2016 10:27:34 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Jiri Kosina <jikos@...nel.org>
Cc: NeilBrown <neilb@...e.com>, kernel-hardening@...ts.openwall.com,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more "safe"
On Mon, Dec 19, 2016 at 02:34:00PM +0100, Jiri Kosina wrote:
> On Fri, 16 Dec 2016, Greg KH wrote:
>
> > > You seem to be targeting a situation where the kernel memory can be
> > > easily changed, but filesystem content cannot (if it could - the
> > > attacker would simply replace /sbin/hotplug).
> >
> > Correct, like an embedded system with a read-only system partition, or
> > for when some kernel bug allows for random memory writes, yet privilege
> > escalation is hard to achieve for your process.
>
> Sorry, I really don't get this.
>
> If kernel memory can be easily changed (which is assumed here), why bother
> with all this? I'll just set current->uid to 0 and be done.
Because you don't want your current process to uid 0, you want some
other program to run as root. It's quite common for exploits to work
this way, take a look at how the p0wn-to-own "contests" usually break
out of sandboxed systems like browsers.
thanks,
greg k-h
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
