The hardlink program 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. The problem can be reproduced by running the program on a directory containing 20 nested directories with 250-character names to get a segfault. 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. ==Solution== http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/hardlink/ For the unsafe handling of potentially changing directory trees, Solar Designer 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.
CVE-2011-3630 hardlink buffer overflows https://bugzilla.redhat.com/show_bug.cgi?id=746709 CVE-2011-3631 hardlink integer overflows https://bugzilla.redhat.com/show_bug.cgi?id=746710 CVE-2011-3632 hardlink symlink attacks https://bugzilla.redhat.com/show_bug.cgi?id=746713
See hardlink.c here: http://pkgs.fedoraproject.org/gitweb/?p=hardlink.git;a=tree Which is completely different program than hardlink from here: http://jak-linux.org/projects/hardlink/ Plus the hardlink in openwall seems to be a third variant but also not same. Anyway, the version 0.2.0 hardlink from jak-linux site is now in Portage as app-arch/hardlink and I doubt this security bug has *anything* to do with it at all I suggest to close "INVALID". Agreed?
The git for the app-arch/hardlink in tree seems to be here, http://anonscm.debian.org/gitweb/?p=users/jak/hardlink.git;a=summary This at least mentions closing of CVE-2011-3632 http://anonscm.debian.org/gitweb/?p=users/jak/hardlink.git;a=commit;h=fc4da208525366aba289c7a150eb8a7d304d2238 And after that a commit like, "Rewrite hardlink in C": http://anonscm.debian.org/gitweb/?p=users/jak/hardlink.git;a=commit;h=bc0a8d544e3866a6ba62ea5f1bf7b8da6e616c11 And a 0.2.0 release few commits after that... Since this was never stable, I guess this could be closed as "FIXED" too
Please, ignore my last comments entirely. I've done a bit more research and got it right now: ' The app-arch/hardlink-0.1.1 we had was Python, and the app-arch/hardlink-0.2.0 is C. Neither of these were the hardlink this bug was filed about. So this would make this bug INVALID. But today, I've committed app-arch/hardlink-fedora to Portage which actually is the same hardlink we are talking about in this bug, so adjusting $summary now. And I've checked that the fixes for these security bugs, close(fd)'s, are included in the upstream app-arch/hardlink-fedora source already. So we have no issues with any of the hardlink's in Portage currently.