83920 2005-03-03 01:28 0000 wget-1.9.1-r3 breaks portage 2005-05-16 22:49:15 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified All Linux RESOLVED FIXED P2 major --- 1 fnevgeny@weizmann.ac.il seemant@gentoo.org fnevgeny@weizmann.ac.il seemant@gentoo.org solar@gentoo.org fnevgeny@weizmann.ac.il 2005-03-03 01:28:39 0000 wget-CAN-2004-1487.patch breaks portage if DISTDIR begins with ".". I use /.n/distfiles where "/.n" is an autofs root. As a result, wget saves files to /_n/distfiles/ instead and emerge fails. Reproducible: Always Steps to Reproduce: spookyghost@blueyonder.co.uk 2005-04-14 02:39:09 0000 wget seems to be mangling names that contain a sequence ".." to "__". If I get a file that is xxx..ogg then this becomes xxx__ogg, xxx...ogg => xxx__.ogg, xxx....ogg => xxx____ogg. If I extract the original wget src and use the command line ./configure && make the resulting wget binary does not have this problem. Modifying the current ebuild and commenting all the epatch lines results in a wget program that will not fetch from http:// urls (others untested). Adding them back one at a time: ipvmisc.patch: OK uclibc.patch: OK locale.patch: OK CAN-2004-1487.patch: broken It looks like the sanitize_path function that is used to prevent undesirable directory traversal is incorrect, it should probably be matching "/../" not ".." etc. seemant@gentoo.org 2005-05-11 05:11:15 0000 solar thoughts? solar@gentoo.org 2005-05-11 09:55:27 0000 Ramndom thoughts per request.. 1) get used to the new behavior. 2) contact upstream about a better fix for the sanitize_path() function. 3) allow user todo his own patching for /../ behavior (which may not be right) 4) see if any other distros have encounted this and what are they doing. 5) don't revert sanitize_path() seemant@gentoo.org 2005-05-16 07:26:53 0000 listen, has -r4 fixed your issues with this? there was a name-mangling patch from mandrake that I had added to it. please report. fnevgeny@weizmann.ac.il 2005-05-16 07:50:33 0000 > has -r4 fixed your issues with this? Nope, all the same. fnevgeny@weizmann.ac.il 2005-05-16 07:58:22 0000 BTW, please restore at least one unbroken ebuild in the portage tree until the bug isn't fixed!! seemant@gentoo.org 2005-05-16 08:05:01 0000 you know -- until upstream releases an update to wget that fixes that can 2004-1487 vulnerability (so that distros don't have to patch it) then we can take it up with them. Until then, your best bet is to patch wget yourself -- or get me a patch to add. Thanks. seemant@gentoo.org 2005-05-16 08:05:33 0000 I cannot restore a security vulnerable version into portage, but you are welcome to download older ebuilds from the viewcvs page off www.gentoo.org. fnevgeny@weizmann.ac.il 2005-05-16 08:44:29 0000 > I cannot restore a security vulnerable version into portage Pardon me? The "fix" which is included in -r3 and -r4 is a security hole by itself, since it results in unwanted directory creation right in the root filesystem. And CAN-2004-1488 is still unpatched (which by all means is more actual than CAN-2004-1487). See http://www.mail-archive.com/wget@sunsite.dk/msg07480.html. > or get me a patch to add. Spooky Ghost (comment #1) has correctly suggested what needs to be changed in the patch. How about Debian's version? http://ftp.debian.org/debian/pool/main/w/wget/wget_1.9.1-11.diff.gz seemant@gentoo.org 2005-05-16 11:53:51 0000 the debian patch looks good to at least solar and me -- so stand by for an -r5 seemant@gentoo.org 2005-05-16 11:56:28 0000 sending this to security@ while I get the new version into portage. GLSA needed, guys? jaervosz@gentoo.org 2005-05-16 13:18:57 0000 thx for the notification, but it doesn't seem exploitable so back to you seemant. [22:16:10] <@taviso> i cant think of any attack vector, just an annoying bug seemant@gentoo.org 2005-05-16 14:02:00 0000 well, -r5 is in portage, and has gotten stable on most architectures as well. thanks for the bug. fnevgeny@weizmann.ac.il 2005-05-16 22:49:15 0000 -r5 works fine. Thanks!