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
-----BEGIN PGP SIGNED MESSAGE----- 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 fd-starvation.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 trivial.
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 libOSWrappersForDummies.so...
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. - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFN5NVYxFmThv7tq+4RAqeNAJ0RZNMD1A7BLTwd5h/lT+rsMwC6SACdF3/R iNTnJnIodTPjcLZRk7PTWgw= =Hgng -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) halfdog (May 30)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) coderman (May 30)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) Andrew Farmer (May 30)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) coderman (May 30)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) coderman (May 30)
- [Security Tool] INSECT Pro 2.6.1 is here Juan Sacco (May 30)
- Re: [Security Tool] INSECT Pro 2.6.1 is here Jeff Blaum (May 31)
- Re: [Security Tool] INSECT Pro 2.6.1 is here Peter Osterberg (May 31)
- Re: [Security Tool] INSECT Pro 2.6.1 is here ichib0d crane (May 31)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) Andrew Farmer (May 30)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) Valdis . Kletnieks (May 31)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) coderman (May 30)
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) halfdog (May 31)
- Message not available
- Message not available
- Message not available
- Message not available
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) halfdog (May 31)
- Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me) coderman (May 30)