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: <20091027110405.GA25845@love.zweije.nl>
Date: Tue, 27 Oct 2009 12:04:05 +0100
From: Vincent Zweije <vincent+bugtraq@...se.xs4all.nl>
To: bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on
 Linux

On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:

||  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.

On Sat, Oct 24, 2009 at 01:46:17AM -0500, Derek Martin wrote:

||  That said, the user in the example already has access to the file (in
||  a running process), and would be able to do so again, *if he had
||  access to a directory where the file was hard-linked*.  Pavel
||  described that the sysadmin checked for that, but even if this worked
||  as expected, there's a race condition where the user could create the
||  hard link after the sysadmin checked, but before the permissions were
||  corrected.  Unlikely, I know... but possible.

That race is easily fixed. After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:

    User1 creates file with permissions 0644
                    User2 opens file for read access on file descriptor 4
    User1 chmod's directory to 0700
    User1 verifies no hard links to file
    User1 chmod's file to 0666
                    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

Excluding the /proc route, at no point during this sequence, User2 could
have opened the file for writing. Therefore, User1 expects (justified,
imo) that User2 cannot write to the file. The writability of /proc/$$/fd/4
violates this expectation.

It is obscure, because it requires User1 to go through an unusual sequence
of steps, but not inconceivable.

||  I don't think what Pavel described is a very serious hole, but it *IS*
||  a hole, because:
||
||  1. It circumvents the fact that to write to a file, you MUST be able
||  to write to its directory, so that the file attributes can be updated.
||  That's an important part of accountability.

As already remarked, this is not true. Write access to the directory is
necessary for creating and deleting the file (which changes the contents
of the directory), but not for writing to the file.

In fact, not even read access on the directory is necessary. Traverse (x)
access on the directory is enough to get to the file (inode, actually);
after that, the file permissions determine what you can do to the file's
contents.

Ciao.                                                            Vincent.
-- 
Vincent Zweije <zweije@...all.nl>    | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)