Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Sep 2017 00:30:46 -0700
From: Eric Biggers <>
Cc: "" <>,
	"" <>
Subject: Re: [RFC] A method to prevent priviledge

On Fri, Sep 22, 2017 at 02:49:59AM +0000, 中村雄一 / NAKAMURA,YUUICHI wrote:
> Hi.
> As we said in Linux Security Summit 2017, 
> we would like to post a patch to prevent privilege escalation attack.
> The concept is here:
> This work is still work in progress and feedback is welcomed.
> Below patch works for linux-4.4.0, 
> To see that it works (try it in a safe place!), 
>  * build vulnerable kernel on Ubuntu 16.04.1 
>    source:
>    please enable "CONFIG_AKO" in kernel config.
>  * try a poc code for kernel vulnerability
>  * look at kernel log, you can see a log that it detected attack like below:
>  AKO: detected unauthorized change of UID. syscall=45 original: uid=1000, euid=1000, fsuid=1000, suid=1000 attempt: uid=0, euid=0, fsuid=0, suid=0
>  AKO: detected unauthorized change of gid. syscall=45 original: gid=1000, egid=1000, fsgid=1000, sgid=1000 attempt: gid=0, egid=0, fsgid=0, sgid=0

You mean a method to *allow* privilege escalation?  This makes stack overflows
exploitable again, and trivially so.  Not to mention that adding one line of
code to the POC to set ->ako_sysnum circumvents this entire "security" feature.

The only way this would be even somewhat sane is if the copy of the credentials
were mapped read-only.  But even then, it wouldn't protect against exploits that
already gain arbitrary code execution (such as your example exploit) --- it
would only protect against exploits that somehow modify their cred struct
directly.  And in that case keeping the cred structs mapped readonly would
probably make more sense...

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.