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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ