[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bugtraq
Subject:    Re: Flaws in recent Linux kernels
From:       Pavel Kankovsky <peak () argo ! troja ! mff ! cuni ! cz>
Date:       2001-10-26 14:22:50
[Download RAW message or body]

On Mon, 22 Oct 2001, Mariusz Woloszyn wrote:

> On Fri, 19 Oct 2001, Martin Kacer wrote:
> 
> >    PS: What about executing suid binary while some other process has our
> > /proc/$$/mem opened for writing? Isn't there the same problem too?
> > Unfortunately, I do not have enough time to investigate that.
> > 
> VERY quick test: opening mem WRONLY returns EINVAL while write().
> Opening mem RDONLY works, but after exec() of setuid binary read() returns
> "no such process".

read() or write() to /proc/*/mem is not allowed unless you access 1. your
own memory space, 2. the memory space of a process you are ptracing (and
the process in q. is stopped).

> Thinking 'bout mmaping and other tricks...

AFAIK, current Linux implementation of mmap() on /proc/*/mem makes a copy
of existing page mappings. You cannot use it to get access to the new
memory space created after execve().

> But opening /proc/%i/exe of a process that executes suid binary works
> well. After exec() another process is able to read suid binary.
> [Isn't it known behavior???]

Excuse me? /proc/*/exe is a "magical" link leading to the file holding a
program being executed. It circumvents directory access restrictions
(nevertheless, you are not allowed to follow the link unless the process
is your own...are you?) but it access restrictions on the file itself
should be checked.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

[prev in list] [next in list] [prev in thread] [next in thread]