Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Feb 2012 17:34:12 +0100
From: Djalal Harouni <>
Cc: Kees Cook <>,
	"Jason A. Donenfeld" <>,
	Solar Designer <>
Subject: Re: procfs: infoleaks and DAC permissions

On Fri, Feb 10, 2012 at 06:36:17PM +0400, Vasiliy Kulikov wrote:
> On Fri, Feb 10, 2012 at 03:06 +0100, Djalal Harouni wrote:
> > A partial fix for this (2):
> > Procfs 'hidepid=' mount option which can be used to restrict access to
> > arbitrary /proc/<pid>/ files, Vasiliy commit [3], congrats.
> > But if the procfs 'gid=' mount option is used then it can give permissions
> > back to read these files if the user is part of the 'gid' group. IOW this
> > will just restore the previous vulnerable situation.
> It is even weaker - you could trick setuid $SPID to open /proc/$PID/maps,
> do exec(setuid_app) as $PID and read setuid_app's maps as $SPID.
Just want to say that I got your point:

I was refering to (2), but your response about 'hidepid' and how to play
with it is more related to (1) setuid self-read and keeping fd opened. The
(ugly) patch I sent will block it.

Spender's patch will do the job.

Note: that trick can give an extra lseek() to the attacker on
/proc/$PID/maps... that will be reflected on the executed setuid_app.


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.