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
| ||
|
Message-ID: <4DE3A214.3080109@halfdog.net> Date: Mon, 30 May 2011 13:56:36 +0000 From: halfdog <me@...fdog.net> To: full-disclosure@...ts.grok.org.uk Subject: 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/
Powered by blists - more mailing lists