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: <87k2b0wus6.fsf@notabene.neil.brown.name>
Date:   Fri, 16 Dec 2016 12:02:33 +1100
From:   NeilBrown <neilb@...e.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        kernel-hardening@...ts.openwall.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/4] make call_usermodehelper a bit more "safe"

On Thu, Dec 15 2016, Greg KH wrote:

> Hi all,
>
> Here's a proof-of-concept patch series that tries to work to address the
> issue of call_usermodehelper being abused to have the kernel call any
> userspace binary with full root permissions.
>
> The issue is that if you end up getting write access to kernel memory,
> if you change the string '/sbin/hotplug' to point to
> '/home/hacked/my_binary', then the next uevent that the system makes
> will call this binary instead of the "trusted" one.

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).

If that is a credible threat scenario, it seems to me that the simplest
mitigation is to have call_usermodehelper always call a single
compiled-in path - e.g. /sbin/usermode-helper - and rely on that
program to validate argv[0] and call it if it is deemed safe.

i.e. get the policy out of the kernel.

Just a thought,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)