Date: Sat, 15 Oct 2011 17:36:36 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: hardlink(1) has buffer overflows, is unsafe on changing trees Hi, The hardlink(1) program from Fedora is susceptible to buffer overflows of fixed-size nambuf1 and nambuf2 buffers when run on a tree with deeply nested directories and/or with long directory or file names. I was able to reproduce the problem (got a segfault) by running the program on a directory containing 20 nested directories with 250-character names. Another problem is that the program uses full pathnames. It neither changes the current directory, nor uses openat(2). Thus, if a pathname component is replaced with a symlink while the program is running, this may result in processing of directories/files outside of the intended directory tree. I fixed the buffer overflows (by (re)allocating the buffers dynamically) in the copy that I committed into Owl today: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/hardlink/ For the unsafe handling of potentially changing directory trees, I simply added a BUGS section to the man page: BUGS hardlink assumes that its target directory trees do not change from under it. If a directory tree does change, this may result in hardlink accessing files and/or directories outside of the intended directory tree. Thus, you must avoid running hardlink on potentially changing directory trees, and especially on directory trees under control of another user. Red Hat and others are welcome to reuse these changes. There's also a lesser problem of potentially reading from a device file or a FIFO if a regular file is replaced with (a link to) one of these. Maybe this problem needs to be documented as well, or it may be patched in the code by always using fstat(2) after opening a file. Only using hardlink(1) on non-changing trees avoids this problem as well, though. Overall, it would be nice if someone rewrote hardlink(1) using fts(3) and in a cleaner fashion. The current program appears to have evolved from a hack that was meant for some very specific use case only. Now that the hack is successful at demonstrating that the program is generally desirable as well as at what problems it should avoid, it may be the right time for a clean rewrite. <offtopic> BTW, hardlink(1) is very useful when run on tzdata - e.g. from %install of an RPM package of tzdata: %install rm -rf %buildroot sed -i 's|@...tall_root@...uildroot|' Makeconfig %__make install hardlink -vc %buildroot This produces the following "verbose output": Directories 69 Objects 1812 IFREG 1743 Comparisons 627 Linked 588 saved 1830912 That's 1.8 MB saved on a filesystem with 4 KB blocks. I got this idea from ALT Linux and implemented it in Owl now. </offtopic> Alexander
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.