[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091028213841.GC8027@elf.ucw.cz>
Date: Wed, 28 Oct 2009 22:38:42 +0100
From: Pavel Machek <pavel@....cz>
To: Marco Verschuur <marco@....nl>
Cc: bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on
Linux
On Tue 2009-10-27 21:19:19, Marco Verschuur wrote:
> My buy.. :-( I persumed a re-use of the read-only FD, but that's not
> the case.
>
> I replayed it on a test-box and did some strace meanwhile and also
> took a look
> at the sourcecode of kernel/fs/proc.
>
> It seems that the /proc filedescriptor is directly referring the
> file inode
> When creating this proc-entry the user guest did have access to the
> file and the path via tmp,
> therefore a successfull filedescriptor straight to the file inode is
> being created, while checking
> th entire path towards the file.
>
> Although closing the path to the file, the actual file is made world
> writable due to the file permissions being 666.
> When guest does the "echo got you > /proc/self/fd/3" the /proc
> filedescriptor (which directly refers the file inode)
> is opened in O_WRONLY. So user guest is able to write the file.
> IMHO; no bug or security issue, just a misunderstanding of the
> mechanism...
Well, existing unix mechanisms would not allow writing to that
file. So yes, it works as authors intended, but I believe it is
misdesigned and security problem.
The /proc/self/fd/X appears to be a symlink, but it is not; it
operates on underlying objects directly. And IMNSHO it should honor
restrictions opened filedescriptors have, like append-only or
read-only.
(Or alternatively, it could be fixed to behave like real symlinks. But
that would break /proc/*/fd/ on deleted files).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Powered by blists - more mailing lists