Bugzilla Bug 83920

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!