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: Tue, 27 Oct 2009 20:09:57 +0300
From: Dan Yefimov <dan@...htwave.net.ru>
To: bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

On 27.10.2009 14:04, Vincent Zweije wrote:
> 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.

No, you're not right.

 > 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

Here's a window, during which User2 is able to create a hardlink and that will 
remain unnoticed by User1. There's no way to perform link check and 
conditionally do chmod in an atomic manner.

>      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.
>
Again, you're not right. See above.
-- 

Sincerely Your, Dan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ