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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091030174028.GA5359@psychosis.jim.sh>
Date: Fri, 30 Oct 2009 13:40:28 -0400
From: Jim Paris <jim@...n.com>
To: Marco Verschuur <marco@....nl>
Cc: Pavel Machek <pavel@....cz>, Dan Yefimov <dan@...htwave.net.ru>,
	bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on
	Linux

Marco Verschuur wrote:

> Your assumption that the same file descriptor is being re-opened is
> wrong!  The file descriptor retrieved via /proc is a new one. It is
> not the same as the initial read-only.

Yes, I totally agree.

> Therefor it's totally of no influence what you do with the original
> directory permission. File access has nothing to do with directory
> permissions...!

Right.  However the whole point of this discussion is that that is a
non-obvious point, there was no other way that the user could have
opened that file without the use of /proc.

> Imagen:
> - a house surrounded with a fence with all doors unlocked (file with  
> perm 0666)
> - a drive-way leads to the gate in the fence and the gate is unlocked  
> (dir with perms 777)
> - next we put a lock on the gate and don't give guest the key (dir with 
> perms 700)
> - guest cannot access the house because he can't pass the gate
> - now we take an airplane and parachute guest straight into the  
> perimeter of the fence (/proc access)
> - guest can access the house (write the file), because the house has all 
> doors unlocked

Pavel required that the superuser have lax directory permisisons and
subsequently make them more restrictive, which led to a flurry of
responses about hardlinks, race conditions, etc.  My example merely
removed this aspect to demonstrate that it is not a race.  In mine,
the directory permissions are 0700 from the start and there are no
races involved.

-jim

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ