Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
coderman wrote: > On Mon, May 30, 2011 at 9:22 PM, Andrew Farmer wrote: >> ... >> You'd think so, but it turns out that --safe-links only affects symlinks >> *within* the tree being synced. > > sure. i should have pointed out the -L in there - that's the one that > will prevent the condition you describe. --safe-links is simply > another good practice by default. > > also, don't rsync from arbitrary locations that differ from backup and > restore. use include-files or exclude-files to control what you care > about... > > (we could go on like this, if you like. for example, extended > attributes. your turn. ;) > My manpage says -L and --safe-links is the same, but using both for testing. # -a is -rlptgoD, only use -r (recursive) -p (preserve perms), # -t (preserve timestamps), -g (preserve group), -o (preserve owner), # not adding -l (copy links) and -D (preserve devices) So test case is, should that be save? rsync -L --safe-links -rptgo xxx/test/root /home/test Still creates arbitrary files outside /home/test, when user test wants it to. Creation of /etc/cron.d/bad does not work, since crond will not accept the file when uid!=0. But adding of backdoor ls in /sbin is ok, so root will use that because earlier in PATH. (uid=0 bash does not care calling executables with uid!=0 if in PATH) -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 coderman wrote: > On Tue, May 31, 2011 at 12:13 AM, halfdog 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/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
On Mon, 30 May 2011 18:54:01 PDT, coderman said: > with a snapshot of a volume at 05/30/2011-18:50:30, you know the > backup process performed on that snapshot is truly a backup of the > data as of 05/30/2011-18:50:30 no matter how long it takes to iterate > over / analyze the files within it. Significant quibble: It's a backup of the data *as it existed on the disk* as of that timestamp. If it's a file that's backing any production database more complicated than the older Berkeley DBM package, it will almost certainly *not* restore to anything usable without help from the database (either by making the database quiesce for a moment while you snapshot, or other methods that are able to ensure a self-consistent version is backed up). I've seen all too many sysadmins trying to figure out why Oracle won't come back up after restoring the file that had the tables in it (And of course, the same issues apply if you're trying to do forensics on a bad backup of a database.) pgpMXZjSnfqBy.pgp Description: 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/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
On Mon, May 30, 2011 at 5:09 PM, Andrew Farmer wrote: > ... > They also don't solve the problem of restoring a fragment of data (e.g, a > single accidentally deleted file) from a backup... if you meant using your backup software for specific restoration, there is no reason you can't do this on the live file system using the backup software as expected. my intent was to encourage use of making / updating the backups on a read-only snapshot of the file system, rather than live. using logical volumes alone are not sufficient for advanced file specific backups/restore or de-dupe or other features traditionally provided by managed backup software. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
On Mon, May 30, 2011 at 6:16 PM, coderman wrote: > ... > there are also [lots of concerns and caveats with using volume snapshots ...] someone asked, "then why use snapshots for backups if difficult?" a backup is represented as a collection of data at a specific point in time. your backup software will traverse the entire collection to perform a complete or incremental archive of this collection. you probably reference it by date, like 05/30/2011-18:50:30. if it takes 45 minutes to traverse a filesystem for backup, what you expect to be backup 05/30/2011-18:50:30 is really a set spanning 05/30/2011-18:50:30 to 05/30/2011-19:20:00 with potentially large amounts of change spanning that time frame and no clue what they were. with a snapshot of a volume at 05/30/2011-18:50:30, you know the backup process performed on that snapshot is truly a backup of the data as of 05/30/2011-18:50:30 no matter how long it takes to iterate over / analyze the files within it. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
On Mon, May 30, 2011 at 5:09 PM, Andrew Farmer wrote: > > LVM snapshots have some nasty gotchas, though: > > https://bugs.launchpad.net/lvm2/+bug/360237 there are also corner cases depending on filesystem used on top of the logical volumes, there is often no fail-safe behavior when you fuck up sizing or lose backing devices, you need to handle application level sync yourself (like locking DB tables and letting buffers flush to disk), etc. did you expect training wheels? > They also don't solve the problem of restoring a fragment of data (e.g, a > single accidentally deleted file) from a backup in an untrustworthy > environment. are you a volume shadow copy user? ;) the poor man's way to handle this is mounting the RO snapshot somewhere, and invoking and rsync, afick, $your_favorite_tool to see what changed and copy/restore what you want. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
On 2011-05-30, at 16:27, coderman wrote: > On Mon, May 30, 2011 at 6:56 AM, halfdog wrote: >> >> It seems that quite a few backup applications are (or were) vulnerable >> to special combined symlink/timing attacks on pathname components before >> the last one (so O_NOFOLLOW does not help). >> ... >> Please let me know, if ... you >> have good reason, that the kernel interface is not the point, where this >> issue could be addressed most efficiently. > > use lvm snapshots for backups, either directly at volume level or > mounting a read-only snapshot and running backup over that static > filesystem state. LVM snapshots have some nasty gotchas, though: https://bugs.launchpad.net/lvm2/+bug/360237 They also don't solve the problem of restoring a fragment of data (e.g, a single accidentally deleted file) from a backup in an untrustworthy environment. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
On Mon, May 30, 2011 at 6:56 AM, halfdog wrote: > ... > It seems that quite a few backup applications are (or were) vulnerable > to special combined symlink/timing attacks on pathname components before > the last one (so O_NOFOLLOW does not help). > ... > Please let me know, if ... you > have good reason, that the kernel interface is not the point, where this > issue could be addressed most efficiently. use lvm snapshots for backups, either directly at volume level or mounting a read-only snapshot and running backup over that static filesystem state. running backups on live filesystems? not a great idea even if these issues resolved. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems that quite a few backup applications are (or were) vulnerable to special combined symlink/timing attacks on pathname components before the last one (so O_NOFOLLOW does not help). E.g. when backup is run as root and crawls though directory structures under control of a malicious user, files outside of this directory might be accessed with the privileges of the crawler process. With backup applications, the malicious user has to be able to have write access at the time of backup generation (read arbitrary file) and must be able to trigger restore of backup, e.g. by use of restore-my-site button at hosters, social engineering or just deleting important files, that someone will miss. When the malicious user is also present during backup restore, he can also overwrite arbitrary files. The net results are: * Access to otherwise inaccessible files (shadow, ssh host keys, files outside chroot/container) on backup * Overwriting of arbitrary files leading to privilege escalation on restore * Escape of container-base virtualization or chroot environments on restore Quite some backup programs can be used in simple symlink attacks, that can be carried out by local unprivileged users. Efficiency boosted to 100% success rate using inotify. Exploitation via network is also possible, but only by trial and error (although a good trial/error strategy should give also nearly 100%). The consequence is, that execution of backup tools on live systems might be a risk, especially restore to a system, where any other processes than user root processes are running, is inherently dangerous. The issue is already known to CERT and major linux distributors, but interest in it is, due to some factors, understandably low, which hampers an in depth fix: * The security problem is caused by a mixture of bad kernel interface design (making it harder to code secure file system recursion programs), bad program design/implementation, and admin error (so efforts in both other domains might be in vain, because of bad program use practice in the end). In the current setting, no one is really in the position to push that forward. * The issue is low priority, because exploitation requires a local, but unprivileged user to write to the filesystem and to trigger a restore of the backup while still having access to the system. In that position, the attacker might use different ways, most of them simpler, to escalate. In the meantime, tar >= 1.25 was fixed to prohibit the arbitrary file theft issue. The root privilege escalation was deemed admin error, hence will not be fixed. In my opinion, syscall interface should be modified to allow simple and secure coding. The suboptimal interface might also have lead to errors in various other applications, that need to avoid symlinks, so that these might be vulnerable to combined symlink/timing also, e.g. how does PHP open files and might concurrent open/relink have the same effect as on backup tools? Till now, it is also not clear, if Windows might be vulnerable. Has Windows symlink-like structures? Does Windows run file system recursion with elevated privileges in userspace, e.g. when syncing user profile with server, when running anti-virus on user data, when running search indexing on disks? Please let me know, if you found other relevant attack scenarios or you have good reason, that the kernel interface is not the point, where this issue could be addressed most efficiently. See http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/ for summary, test cases and reproducers, references. - -- 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) iD8DBQFN46ISxFmThv7tq+4RAn5IAJ9ILZCCrCOKaSQnttqQwgKYE6+uPACdEeN/ NO+O6HkZM3fV1Ek0Xay7aRU= =l+GW -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/
