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:
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.
solar thoughts?
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()
listen, has -r4 fixed your issues with this? there was a name-mangling patch from mandrake that I had added to it. please report.
> has -r4 fixed your issues with this? Nope, all the same.
BTW, please restore at least one unbroken ebuild in the portage tree until the bug isn't fixed!!
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.
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.
> 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
the debian patch looks good to at least solar and me -- so stand by for an -r5
sending this to security@ while I get the new version into portage. GLSA needed, guys?
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
well, -r5 is in portage, and has gotten stable on most architectures as well. thanks for the bug.
-r5 works fine. Thanks!
