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