Bug 83920 - wget-1.9.1-r3 breaks portage
|
Bug#:
83920
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: major
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: seemant@gentoo.org
|
Reported By: fnevgeny@weizmann.ac.il
|
|
Component: Core system
|
|
|
URL:
|
|
Summary: wget-1.9.1-r3 breaks portage
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-03-03 01:28 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:
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.
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.
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.