Dangerous Vulnerability Fixed In Wget 58
jones_supa writes: A critical flaw has been found and patched in the open source Wget file retrieval utility that is widely used on UNIX systems. The vulnerability is publicly identified as CVE-2014-4877. "It was found that wget was susceptible to a symlink attack which could create arbitrary files, directories or symbolic links and set their permissions when retrieving a directory recursively through FTP," developer Vasyl Kaigorodov writes in Red Hat Bugzilla. A malicious FTP server can stomp over your entire filesystem, tweets HD Moore, chief research officer at Rapid 7, who is the original reporter of the bug.
Wget (Score:2, Funny)
Is that the tool you use to download IE ??
Erm... wait, that wasn't right....
Re: (Score:2)
Re: (Score:1)
Debian updates (Score:2)
Well as I read this article, I just apt-get upgrade my system and voilÃ, vulnerability fixed. This is not to say "haha Debian p0wnz you" because any *serious* distro would be that reactive, I just find that's awesome to have patches available so quickly after a flaw is found.
super user (Score:2, Insightful)
so dont run wget as root?
Re: (Score:2)
You should not do that anyways.
Re: (Score:3)
Whoosh.
Re:super user (Score:5, Interesting)
Yes that's good practice for any command. Though wget is used behind the scenes by, say, opkg on openwrt boxes, which has to run as root since it's unpacking and installing packages. In fact on embedded devices, most everything runs as root there, typically, even if it's a bad idea, and is going to have to change as the internet of things becomes a fact of life. Never thought I'd need to run selinux on an embedded device, but we're to the point now where that's required.
It's good to have this particular bug fixed at least.
Re: (Score:3)
I was going to make essentially the same comment. Someone is going to jump in and suggest that utilities like that should have their own user account and call sudo or fork and su to start wget as the limited user, and fetch certificates to some specific directory.
Those someones are probably correct, but we all know in practice that rarely happens.
Re: (Score:1)
Never thought I'd need to run selinux on an embedded device,
Luckily at a point when the CPU and disk space of many embedded devices is now affordably at a point that makes the extra overhead viable.
Re: (Score:2)
wget isn't unpacking and installing, it should not be run as root.
Re: (Score:1)
If it's installing packages it can pwn your box anyway, no wget vulnerability required.
Re: (Score:2)
Yes but, I would hope that an installation of openwrt is getting it's packages from a highly trusted source. If the source is using a bug to damage your system then you've got a lot more problems then wget.
Re: (Score:1)
Never thought I'd need to run selinux on an embedded device
So, instead of using a program with a known vulnerability that's being fixed as we speak, you want me to run NSA code? FUCK OFF SHILL.
SELinux is dead to me, regardless of whether it might or might not be safe to run. I refuse to trust anything that they've gone anywhere near. It's like how FTDI fucked up. You lost any trust I might have had, and I'm not auditing your piece of shit. I'm walking away from it.
Is busybox wget vulnerable? (Score:2)
Re: (Score:1)
(But then again I wouldn't believe that home routers could be sold with an internet-facing backdoor open by default in their stock firmware, until that happened.)
Re: (Score:2)
No, it doesn't. A safer architecture would be to use an unprivileged user for downloading and only use root for installing.
Re: super user (Score:4, Insightful)
Re: (Score:2)
rapid7.com metasploit & kb.cert.org advisory (Score:4, Informative)
- The disclosure is here:
https://community.rapid7.com/c... [rapid7.com]
- Vulnerability Note VU#685996 (kb.cert.org):
http://www.kb.cert.org/vuls/id... [cert.org]
Re: (Score:1)
- A Metasploit module is available for testing:
https://github.com/rapid7/meta... [github.com]
Re: (Score:2)
The two terms are not mutualy exclusive
Re: (Score:1)
Yes, it is Free Software, but it is Open Source too.
GNU Wget is licensed under GPL 3 or above, and GPL 3 is an OSI-approved Open Source licence [opensource.org].
Nothing to see here, move along (Score:5, Informative)
Bug found, bug fixed, another venerable tool got even better. This is just business as usual.
Re: (Score:1)
not true - several distros have yet to publish anything or upgrade.
this is important news not easily swept away by hand waving.
Re:Nothing to see here, move along (Score:5, Informative)
Very moderately so. Of course, you should not wget to not trustworthy servers until you have a patched version. But you should not do that anyways, even with the patched version. The biggest risk is still what you get from the server, even if it is confined to its intended place.
Of course, for clueless people using insecure practice, this issue may have some importance. The others are not really at risk and will get the information anyways from the vulnerability information feed of their choice.
Re: (Score:2)
wasn't this addressed in February?
https://www.redhat.com/archive... [redhat.com]
Neat. (Score:5, Insightful)
Neat trick.
But if you have arbitrary FTP URL's from untrusted sources piped straight into wget on a server you run, you have bigger problems than someone trashing your filesystem or overwriting your /etc/passwd.
Switching to windows (Score:5, Funny)
Too tired of this kind of crap from the open source community
Re: (Score:2)
Re: (Score:2)
FTP? (Score:1)
The vulnerability is only exploitable when fetching an FTP directory, recursively, from a malicious server.
Yeah, it's a hole, but it's not shellshock. Stop bitching around and just update your box.
Re: (Score:2)
And only as the user running wget.
If someone can replace the URL's passed to wget as root, presumably it's only a small step to actually have them execute without needed wget to actually overwrite existing filesystem files.
Re: (Score:1)
Indeed. It cannot even be used with anonymous FTP to a site with full permissions on /incoming, it requires a symlink and a directory WITH THE SAME NAME, and no regular file system would allow that. So the FTP daemon needs to be specifically designed to send this.
So yeah, unless ftp.redhat.com gets broken into, and the attacker gets root access to be able to replace ftpd, you don't need to worry about your package manager using wget to download stuff.
And it only affects recursive downloads, so using wget to
Re: (Score:2)
Heartbleed, poodle, shellshock (Score:1)
Where's the catchy buzzword to scare management?
Not a problem if you have MAC (Score:1)
running strings on bad file also unsafe (Score:3)
Slightly related;
Lcamtuf writes that that running strings over a maliciously crafted file can probably result in code execution on your system.
http://lcamtuf.blogspot.co.uk/2014/10/psa-dont-run-strings-on-untrusted-files.html [blogspot.co.uk]
The big picture is nothing new, when you use software, particularly software which is written in C/C++, to process data from untrustworth sources there is a reasonable chance of hard to spot security vulnerabilities.
Re: (Score:3)
So, will this new bug be called... (Score:1)
"The Hot-link Injection"?? Sounds pretty spicy.