linux-kernel - Re: [RFC 0/4] make call_usermodehelper a bit more "safe"

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: <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