bugtraq - Re: /proc filesystem allows bypassing directory permissions on Linux

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: <20091026161436.GA21590@mercury.spuddy.org>
Date: Mon, 26 Oct 2009 12:14:36 -0400
From: Stephen Harris <bugtraq@...ddy.org>
To: Dan Yefimov <dan@...htwave.net.ru>
Cc: Pavel Machek <pavel@....cz>, bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

On Sat, Oct 24, 2009 at 02:31:47AM +0400, Dan Yefimov wrote:
> On 24.10.2009 1:56, Pavel Machek wrote:

> >a) this kind of hardlink does not exist when /proc is mounted (and on
> >non-Linux)

> >(and c) writing to file descriptor opened read-only is bad).

> Did you think of creating a hardlink to the file in an unrestricted 
> location?

Pavel considered that in his original mail, where he checked there were
no links.

Pavel wrote his email in a convoluted way, so it's not clear what's going
on.  Here's an attempt to rewrite:

User1 creates file with permissions 0644
                    User2 opens file for read access on file descriptor 4
User1 chmod's directory to 0700
User1 chmod's file to 0666
User1 verifies no hard links to file
                    User2 can not open the file for read or write access
                    User2 can not write to file descriptor 4
                    User2 _can_ write to /proc/$$/fd/4

Now user2 is expected to be able to have read-access to the file via
(he opened it in step 2).  If he attempts to write with ">&4" then it
silently fails (on Linux, anyway).  But access via /proc/$$/fd/4 allows
write access.

The real concern appears to be that user2 can write to a file descriptor
opened for read access.

A fix would be to have a mask against every procfs "fd" entry that matches
the open() mode of the file descriptor (or perhaps the mode of the file
when it was opened?).  Thus a write to /proc/$$/fd/4 would fail because
the mask on fd4 would be "read".

I think this is of (very) small concern (no one in their right mind
would do this) but it is an unexpected result and breaks the principle
of least surprise.

FWIW, the same "issue" exists on Solaris 10.  It's not Linux specific.

-- 

rgds
Stephen