Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
From: halfdog <me () halfdog net>
Date: Tue, 31 May 2011 11:47:43 +0000

Hash: SHA1

coderman wrote:
On Tue, May 31, 2011 at 12:13 AM, halfdog <me () halfdog net> wrote:
... Yes, absolutely correct. Only working through the path using 
fstat/openat with O_NOFOLLOW and keeping every dir-fd open would
allow to make sure, that no links are followed -- at the risk of

keeping every dir-fd open? not necessary.

Keeping the last dir-fd open and the fd to the file to modify would be
sufficient when only one file should be modified. When performing
recursion over tree, you will have to open the directories up and down
the tree, which might impede performance.

And if not keeping them open, the first normal open/stat call will be
the first one leading to misery.

These questions are remaining open:

Is the existence of a whole group of symlink/timing vulnerable 
applications, that are currently used on symlinks in racy live
systems, a hint, that there is something fundamentally wrong in
that area?

it's a hint that directory traversal in a secure manner is not

Of course, but could it be made simpler with additional syscalls, e.g.
OPEN_TRUSTED or OPEN_NOLINKS, that can operate on path components?

just like secure development in general is not trivial.

Hear, hear

there are file systems which don't support symlinks or hardlinks.
yet they are also less useful in practice.

Of course, they are useful to map parts of the filesystem. But the
userspace has no simple, secure and atomic means to access the
filesystem. I would wish for an atomic open call using a pathname, that
would check on OS-side:

* That I do not leave one filesystem
* That all path elements and symlinks are owned by me or a user with
higher privileges
* That all the elements cannot be modified by any other user with same
or lower privileges, e.g. due to open permissions (0777)

It would be nice, if the call could also consider the
security-classification of the device, that was specified during mount,
e.g encrypted partition mount = 100, normal partition mount = 0, trusted
nfs = -100, usb = -200 ... and so on. The open does only succeed, if all
elements in the trust chain have security >= 0.

Even if this is bad filesystem/kernel interface design, in the
light of other vulnerabilities, should one care about it, e.g. to
implement a "secure fs syscall"?

you create secure_recurse_dir() to fit all needs, more power to you. 
still should not go in syscall or stdlib, perhaps 

That means, that tar/rsync/cpio/cp/ls and all applications using those
commands were not designed with security in mind? Or were the developers
not caring or smart enough to do it right?

Please consider also, tar format is POSIX standard since 1988, I do not
know, how old the GNU tar implementation is. But since ages, the read
file inclusion issue was never found during any audits or whatever,
until fixed last year.

- -- 
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
Version: GnuPG v1.4.6 (GNU/Linux)


Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]