Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Unix Bug Security Software Linux

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.
This discussion has been archived. No new comments can be posted.

Dangerous Vulnerability Fixed In Wget

Comments Filter:
  • Wget (Score:2, Funny)

    by Anonymous Coward

    Is that the tool you use to download IE ??

    Erm... wait, that wasn't right....

    • by fugas ( 619989 )
      There's actually a tiny implementation of wget for Windows that I've been using for that type of thing precisely ;) It's called nugget, doesn't have all the bells and whistles of wget but still has some pretty interesting and unique features. Don't have the URL at hand, though.
    • by tyggna ( 1405643 )
      It's the tool you use to download elinks
      • 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)

    by goombah99 ( 560566 )

    so dont run wget as root?

    • by gweihir ( 88907 )

      You should not do that anyways.

    • Re:super user (Score:5, Interesting)

      by caseih ( 160668 ) on Wednesday October 29, 2014 @11:20AM (#48261081)

      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.

      • by DarkOx ( 621550 )

        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.

      • by Anonymous Coward

        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.

      • by Qzukk ( 229616 )

        which has to run as root since it's unpacking and installing

        wget isn't unpacking and installing, it should not be run as root.

      • by Anonymous Coward

        If it's installing packages it can pwn your box anyway, no wget vulnerability required.

      • 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.

      • by Anonymous Coward

        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.

      • I can't tell from their website.
      • It's not enough to download some files: in order to be susceptible to the attack, those devices should download stuff as root in recursive mode from a compromised ftp server. I honestly can't see that happening in reality.

        (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.)

      • 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.

        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)

      by undisclosedrecipient ( 1454713 ) on Wednesday October 29, 2014 @11:49AM (#48261377)
      Root access is the worst case indeed, but it's not a silver bullet if what you really want to protect is accessible by current user. I've seen my share of magical thinking banning root at all costs while in fact confidential data can be grabbed by an exploitable non-root user.
    • I run everything as root because YOLO. I'm not gonna be guessing perms and retyping commands, son. I got shit to do.
  • by Anonymous Coward on Wednesday October 29, 2014 @11:17AM (#48261041)

    - 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]

  • by gweihir ( 88907 ) on Wednesday October 29, 2014 @11:21AM (#48261091)

    Bug found, bug fixed, another venerable tool got even better. This is just business as usual.

    • by Anonymous Coward

      not true - several distros have yet to publish anything or upgrade.

      this is important news not easily swept away by hand waving.

      • by gweihir ( 88907 ) on Wednesday October 29, 2014 @11:31AM (#48261179)

        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.

    • by jsepeta ( 412566 )

      wasn't this addressed in February?
      https://www.redhat.com/archive... [redhat.com]

  • Neat. (Score:5, Insightful)

    by ledow ( 319597 ) on Wednesday October 29, 2014 @11:27AM (#48261141) Homepage

    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.

  • by Anonymous Coward on Wednesday October 29, 2014 @11:43AM (#48261305)

    Too tired of this kind of crap from the open source community

    • Don't forget to manually update all the patches that should be part of a service pack before connecting to the network. Especially the ones that patch the Windows Update service that fix errors where Windows Update can be tricked into downloading and installing anything from anywhere.
  • Anyone read the article?
    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.
    • by ledow ( 319597 )

      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.

    • by Anonymous Coward

      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

  • by Anonymous Coward

    Where's the catchy buzzword to scare management?

  • This is why I use AppArmor
  • by throwaway18 ( 521472 ) on Wednesday October 29, 2014 @02:35PM (#48263083) Journal

    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.

    • Does anyone run "strings" on files they know enough to "trust"? It's essentially a "What the hell is this file? Let me see if it has any useful text strings in it that might give me a hint" tool.

  • "The Hot-link Injection"?? Sounds pretty spicy.

Of course there's no reason for it, it's just our policy.

Working...