Date: Fri, 06 May 2011 18:54:20 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Re: Symlinks and filesystem recursion vulnerabilities: Action needed or ignore? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Christey wrote: > > Assuming I understand the issue correctly, there is precedent in CVE > for this kind of problem, or at least the exploitation of recursive > backup/archive programs as they process files (many seem related to > setting insecure permissions during the copy, and only setting the > secure permissions afterward, a la CWE-689). No, it is not a permission problem. Even with correct permissions, that disallow user x to access a file, he can make a recursion program of another user holding that permissions to access the file. Since backup is usually run as root, permissions will not stop that from happening. > CVE-2009-4411 is the only example I can easily find. As I understand it, this one is slightly different to this problem, because application simply does not check against symlinks correctly and hence may fail, even in a single-user environment. The problem with tar et. al is, that they correctly follow only physical path when run on single-user environment, but may fail, when run on untrusted directory controlled by malicious user due to TOCTOU. > There is a "risk" of sorts to the community that a large number of > these issues could get disclosed for different packages in a short > timeframe, but this happens with any discovery of a new "class" of > security problems or attacks (look at the untrusted path stuff that > happened last year with Windows and Linux). But IMO, better sooner > rather than later. Linux is a multi-user OS and should be treated as > such, which means local file-writing/privilege attacks matter, even > though they might not be as severe as other kinds of attacks. > Somebody audited simpler symlink problems in Debian packages a couple > years ago, but while it must have been very painful and there were > dozens (hundreds?) of separate issues, most of those problems seemed > to get fixed in a relatively quick amount of time. Well, the read problem is fixable, but might cause regressions. I'm not sure if the numerous regressions after the tar fix were the cause of the symlink fix itself (or due to unrelated cleanup also happening during larger code rewrites), but there were some quite annoying problems, some of them still exist. The question is, if the regression risk is higher than the security risk. The write example, that is leading to immediate root priv escalation, is caused by admin error. But since nearly no admin knows, that it is nearly impossible to securely restore a backup to a live system, they are not really to blame. This issue could be "fixed" creating awareness. A final fix would be much simpler, if a safe open call is provided by the OS. I do not know, if there are some flag bits available to modify current open or if a new SecureOps-Syscall (could be used as generic gateway for various sec-related calls) could be implemented. From my point of view, kernel implementation should be rather simple, user space would also be technically simple (libsecureio.so or addon to libc). But I do not know, if such a change would ever be accepted by community and standardization boards. > Maybe the appropriate strategy is for the community to agree on a > good way of solving these problems before announcing all the > different packages that are affected, but it's just a thought. > Ultimately this decision is up to the researcher, affected > developers, and customers. Where could be the right place to find that decision? CERT said, that they do not plan any advisories, which does not mean that they do nothing on the problem, but I think, they see it low risk/low priority, which I can understand in some parts. hd PS: Has someone windows knowledge and programing skills to see if only linux-OS is affected? Would require existence of symlink-analoge structure, and would be more effective if inotify-like calls would be possible. Could the profile synchronization at login be used to take over a windows box at system level? Would also require sync to run at elevated privs. - -- 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) iD8DBQFNxEMdxFmThv7tq+4RAgAvAJ93fv3c9r0tZjYrcNAcGJYL6ux71gCcCnEO rotufy+xVYEzBRIZVTjJFRQ= =K218 -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.