The NO-NAME vuln: wget mess patched without a fancy brand Sysadmins: another venerable and nearly-ubiquitous *nix tool, wget, needs patching because of a bug first reported by HD Moore. As the Red Hat Bugzilla report describes, the bug was a beauty: a recursive directory fetch over FTP would let an attacker “create arbitrary files, directories or symbolic links” due to a symlink flaw …
I also can't see how it's going to “overwrite your entire filesystem”, since unless you are logged in as root (in which case why are you doing that?) wget isn't going to have permission to write anywhere except your local account. *I* can't overwrite my entire file system while sitting in front of my computer without entering the password first. In addition, wget has "anti-clobbering" built in as default, so it won't overwrite your files unless you tell it to.
Here's what the discoverer *actually* said: "access to the entire filesystem with the permissions of the user running wget". In other words, the downloaded files could include symlinks which allow files to be *read*. However, that only happens if you can read those files *without* the symlinks anyway.
The actual attack seems to be to set symlinks to other parts of your file system so that you are reading the wrong copies, rather than files actually being erased. The symlinks only happen if the source file layout is set up a very specific way (it doesn't happen in normal use). I won't try to repeat the whole process in this comment. You then need to arrange things somehow so that some other program (e.g. cron) reads that symlink and uses that data in some fashion.
The exploit he described seems to be rather long and complicated and needs root access plus the presence of at least one program that I don't have installed, so I didn't try it.
The problem is fixed upstream and fixes should be coming out quickly. In the mean time, anyone who is worried about this can simply specify --retr-symlinks. The actual fix simply makes this option the default.
Anonymous Coward - "Urm, don't things like apt and yum use wget to do the actual fetching of packages? Those are run as root."
If an attacker has control of the repo you are fetching packages from, then they really don't need to bother with round about methods. They just have to push an update out with whatever they want in it. The same applies to MS Windows Update (or whatever they call it) or Apple's equivalent. If someone controls the source of your updates, they control your PC.
This issue only realistically applies to your doing a mass wget on a web site which the attacker controls, plus the attacker having some way of taking advantage of it which applies to your PC.
Of course *any* bug like this should be fixed, as even seemingly minor ones because someone may find a non-obvious way of taking advantage of it which is worse than you anticipated.
This is also why security fixes really ought to be pushed out right away, rather than once a month like Microsoft does. I'm writing this on an Ubuntu system, and the fix has already come through the normal update system and installed (the updater icon appeared in the launcher bar, click on that, and then click 'OK' to accept the updates).
Well, they would need to get both an SSL certificate and a code-signing cert that match Microsoft's public keys for both (the expected public key is shipped with Windows, and any updates to those keys are signed by the one before it).
It can be done, but it would take a really sophisticated attack campaign or the backing of a very powerful government. Of course while their is a guarantee that it hasn't been tampered with, there is no guarantee to the quality of the code itself...
True, you can't p0wn the machine unless running as root (why? really why do that?)
But you could get up to lots of mischief by overwriting the user's own files, maybe starting with something creative in .bashrc
<twiddles moustache like a cad & bounder>
Can we have a Terry Thomas icon please?
> you could get up to lots of mischief by overwriting the user's own files
Indeed. Just think for a moment where the valuable and irreplaceable data in your system is; the photographs, the document archive, the password vault... All in /home/yourname, probably owned by your user and group. If /boot is overwritten, that's recoverable. Even /, if you have /home on a separate filesystem [1]. But if someone symlinks all over /home, then it's going to be time to restore from backup.
[1] Such a setup was one of the things recommended in the first Linux I ever installed, I've done it ever since, and thoroughly recommend it.
Admittedly it can be an incredibly convenient facility... but I always prefer to download whatever it is I require onto my workstation first and then upload via SFTP onto my server. I do however always maintain an absolutely minimal installation for this very reason. Less binaries = less vulnerable code.
And as per the Bugzilla report this vulnerability was originally reported on 2014-Sep-08... almost two months ago.
I guess it depends on your server. I thought it was installed by most distros by default but I don't know how many people routinely use it for mirroring stuff. I tend to use wget over curl because the incantation is easier. But I might just install fetch for remote downloads.
Your point about code that isn't there can't be attacked still stands but in that case why even have an SFTPd running. Surely, the really safe thing is to be able to read the files from a remote file system under your control? Even then, can you be sure the files aren't corrupt?
This post has been deleted by its author
Dunno, but I think it's a good thing. Too many *nix devs have been complacent for a long time "because *nix is designed to be secure, we don't viruses" and the whole meme of "it's open, lots of eyes can see the code" sort of security feel-goodness.
Going bug hunting in the stuff we've taken for granted for so long can only improve things for all. After all, how are we to be sure that Govt. spy agencies are not already aware of many of these "newly discovered" holes?
(FreeBSD use since 4.3-Release)
I've always hated that thought, just because a lot of people *can* see the code, doesn't mean that they *are* or even that they understand what they see. Most of the time I see it as an excuse to not bother with verifying code because someone else will. You end up with things like OpenSSL that had a lot of eyes looking at it, yet no one noticed Heart-bleed for quite some time.
Wget has a windows version too. I presume it's as vulnerable.
I also presume that on all versions Wget can only overwrite directories you have permission for.
Also on Windows as well as Linux if you bother to install:
X
Bash and other shells
Gimp
Libre Office
Thunderbird
Firefox
Wget
dd (raw byte copy direct to devices)
Putty
Filezilla
Mysql
Apache
... and many other programs / utilities
Let me see if I understand that right. The bug is it could create symlinks and then follow those symlinks so it would actually be writing outside the intended target directory. Is that accurate?
Also, it doesn't sound like it's exactly fixed. All they did was turn off creating symlinks by default. So if you ever actually needed that and turned it on you'd still be vulnerable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
