Wu-ftpd Remote Root Hole

Ademar writes: "A remote exploitable vulnerability was found in wu_ftp, which is distributed in all major distros. The CERT has a (private) list to coordinate this kind of disclosure so vendors can release updates together, but RH broke the schedule and released their advisory first. You can see the full advisory from securityfocus in bugtraq, but here is a quote: "This vulnerability was initially scheduled for public release on December 3, 2001. Red Hat pre-emptively released an advisory on November 27, 2001. As a result, other vendors may not yet have fixes available."" CNET has a story about this too.

Wu-FTP not in OpenBSD

[Geekboy(Wizard)]

Wu-FTP is not in OpenBSD, and ftp is disabled by default. Wu-FTP is not included with all major distributions, but possibly in Linux ones.

You're a nit. You're a nit. Here's another one!

I've changed my mind

[child_of_mercy]

Would have been nice to give the maintainers on a few other distro's time to close the hole before broadcasting this to the script kiddies

Until 5 mins ago I was a beleiver in complete disclosure,

But with 6 wu-ftpd boxes to admin I'm not so sure any more.

Hope I see a fix today.

linuxtoday.com

[jonsmirl]

Is this how Linuxtoday was just hacked?

My favorite quote

[Reality Master 101]

The problem, known in security circles as the wu-FTP Globbing Heap Corruption Vulnerability, allows attackers to get remote access to all files on a server, provided they can access the FTP service.

Whew! Your whole system is only wide open if you can access the FTP service. That makes me feel better!

CERT and private lists

[SClitheroe]

You all bashed Microsoft the last time around for not immediately and publicly notifying users of an exploit, they, prefering instead to ready a fix before the exploit was common knowledge.

So, once again use an occasion such as this to resoundingly denounce the fact the CERT, and major Linux distros other than Red Hat, have chosen to do the essentially same.

I suspect that the complaints of this type of behavior will be much less in the case of CERT, since Microsoft's disclosure policies simply allow slashdotters to take pot shots at MS, but we'll see...The shoe's on the other foot this time.

Re:Nice.

[dlek]

According to the CNET article [cnet.com], Red Hat did this by mistake, and they apologized.

I'm somewhat surprised--but either way it brings the unresolved question of disclosure bubbling to the froth again.

Know what you're doing.

[rice_burners_suck]

I think it's better that Red Hat released the advisory ahead of time. The faster sysadmins, programmers, and other users know about remote root exploits, the faster the exploit can be closed.

Of course, there are some folks out there who won't patch their system. For those people, advisories like this don't help at all. But then, if you're running anything important, you should take the time to learn how to properly configure and maintain the system. Trying to hide known exploits from the public only serves to make things more difficult and dangerous for those of us who DO know what we're doing.

In other words, if you don't know what you're doing, you shouldn't be using a computer.

OH WELL.

Re:Another globbing bug?

[LS]

Ok, so what level of security on someone's box makes them no longer a moron? Is there a canonical list of things I must do to secure a box so that I am no longer a moron? To be honest, I run my own box for personal use, and learning anything more than basic security takes more time than it's worth. Please let me know where I can go to learn what it takes to build a secure box as defined by non-moron security experts.

LS

Secret awareness of security exploitability: scary

[sanermind]

It disturbs me that a formal process of keeping newly discovered vulnerability information from the public seems to be becoming the norm. I would feel much safer if we were informed right away of a known remote execution vulnerability, so that we can assess the risks ourselves, and make the appropriate decision as to whether to disable the service, or switch to a different implementation.

I just know that the powerful interests, not just the federal government, but also foreign governments and corporate espionage types, become aware of these things, and likely have crack teams of dedicated crackers to rapidly turn out an in house exploit.

Asymetric information is inequitable, giving an inevitable advantage to the elite in the know.

Lack of knowledge is powerlessness.

Re:My favorite quote

[great throwdini]

For outgoing data, you can just use HTTP.

I don't think routing all data transfer through HTTP is a panacea... perhaps it offers better "out of the box" security than your average FTP service, but your comment smacks of the tendency to run with port 80 [slashdot.org] hashed and rehashed earlier on Slashdot.

You're comments are spot-on as far as trust and public access are concerned, I simply question the view that HTTP is a simple (and better) replacement for FTP. Obviously, FTP implementations have their issues (and *big* ones, too) with security, but to me, HTTP can't really offer all that FTP does in terms of file transport.

Please correct me if I'm wrong.

Minor unrelated peeve: why is it that Slashdot's search indexing exclude words of fewer than four characters in length? Silly ... I couldn't search for XML as a keyword, and had to hope that SOAP made due appearance in the article I reference.

ironic..

[LinuxHam]

Just today someone at work emailed those of us on some Linux contact list, asking for suggestions from us on how we secure wu-ftpd. I replied that it's a lost cause. For authenticated ftp, I do scp now, even with Windows clients, and for unauthenticated ftp, I just do http. Its an easier workload for the system and its much easier to cluster for higher availability.

Then this comes out. I hope he got my email. :-/

Re:Wu-FTP in Debian but not as default

[michael]

My suggestion is that you do instead:

#apt-get install bsd-ftpd

which is a port of the audited OpenBSD FTP server.

Ok - What does this attack LOOK like?

[rjamestaylor]

I just found one of our servers (which I did not have primary responsibility over) was running the latest version of wu-ftpd... so, what does one of these latest attacks look like (don't say "liuxtoday.com")? How could I spot an attempt in /var/log/messages?

Re:Nice.

[sheldon]

Gary McGraw [cnet.com] must be a troll as well. He even mentioned this in a book he wrote.

What's open source's role in the security-by-obscurity debate?

Open-source software is neither more nor less secure than closed-source software. And the whole issue of whether open source is more secure is a red herring. We have a chapter in the book about it. Security by obscurity doesn't work. But just because you have your source code sitting around in public doesn't mean someone's going to do a free security review on it, either, which is what the open-source guys think. That's wrong.

Re:My favorite quote

[great throwdini]

• both require a new connection for each dir listing or file transfer - except HTTP/1.1 which can reuse a connection. HTTP wins.

  Only for 1.1 ... I don't see the viability yet [slashdot.org].

• FTP requires an additional TCP connection for the control info. More setup and teardown cost. HTTP wins.

  OK. I guess I'm more concerned about access (how people get files) more than anything else. HTTP/1.1 (which I see as offering the tools needed to surpass FTP) may have to make use of a second connection at times, IIRC, though.

• Many sites are already running an HTTP server, so using that for file transfer means one less daemon. Mitigated by running ftpd out of inetd, which most people do, but still ... HTTP wins.

  I'll grant this, too. But where's the application support beyond "see the file, click on the link"? Please point me in the direction of a robust and well-supported HTTP agent that can duplicate the functionality of any standard FTP client. Please.

• HTTP can use auth methods other than plaintext, and can easily have different sets of auth'd users in different directories

  I'm not so certain about this. I haven't seen many auth methods implemented in clients other than https, where you incur certificate fees and more mess than "just one less daemon" implication.

What are the advantages to FTP for downloads ... I honestly can't think of any ATM.

Well... implementation-specific, but:

1. Error recovery and restart from an arbitary point in a given file;
2. Recursive download;
3. On-the-fly authorization switching (USER command);
4. variable -- APPENDing, unique filename, overwrites, allocation requests, etc. -- storage (ok, this is for uploads, but...); and
5. The flexibility of a system built for file transfer... this is what I'm looking for and it is difficult to describe succinctly. Is there an HTTP client as friendly and flexible as FTP as far as the mechanics of file access is concerned?

To name a few. Some of this could be implemented using HTTP/1.1, or with a smart HTTP client... but where is it? Maybe for single-file downloads and a willingness to kludge together webpages to present data, but that's not enough. It could be, but I haven't seen anything really flexible.

The flexibility in presentation and access could exist, but until it does, FTP will not be displaced, IMHO. I'd love to be proven wrong, though.

Re:Ok - What does this attack LOOK like?

[Geekboy(Wizard)]

Quoted from The Register:

"The hole is the result of a programming error in the portion of WU-FTPd that processes file names containing special characters. BindView's Matt Power discovered in April that the server would crash if presented with the file name '~{', but the program's maintainers believed the bug could not be exploited. "

URL for the article is http://www.theregister.co.uk/content/4/23082.html [theregister.co.uk]

Re:more to the story

[Phexro]

how about "the wu-ftpd developers weren't aware that this bug was exploitable" - since it was discovered soon after 2.6.1 was released, but they decided not to fix it.

don't get me wrong here - i don't use wu-ftpd, either. i use the openbsd ftpd [debian.org] ported to linux.

i just felt that people should be aware that there was more to the story.

Re:I've changed my mind

[reflective recursion]

For example, say I develop a new top secret encryption scheme, called Rot-13. I tell no one of how it works. Since I am not a professional cryptographer, the chances are my algorithm is not cryptographically sound. So it is only secure as long as its method is secret. Once the secret is out, its security is gone. This is security through obscurity.

Okay, but you still have some security there (not very much of course).

An example of the opposite would be RSA. The algorithm is well known, therefore with peer review, it is thought of as secure. Even though I know how RSA works, I'm still unlikely to be able to crack it if used properly.

I believe this is flawed thinking in regards to security. I'm sure you have seen the many times on Slashdot that such-and-such method of encryption, which everyone believes to be the most superior, gets cracked in a matter of days. Then I hear "it was cracked by a team" or "it took 4 days." This lessens the impact and makes it appear as if RSA is still very secure.

I believe it is a huge flaw to think RSA will keep you safe because it is well known and peer-reviewed. It may be secure from those script kiddie attacks, which would only install an IRC bot or maybe erase your hard drives. It is not secure if you ever run into someone with a strong motivation to get into your system. The same strong motivation that was able to break the such-and-such encryption in only so many days.

Another problem with open security methods is that they can be detected. If you don't tell anyone what encryption method you are using on a certain site then it will be hard to break in. Now, if you don't tell anyone (obscurity), but you use a well known algorithm (peer-reviewed) then your security method is more easily detected. Crackers will pick up on certain reoccuring bit-patterns, the length of the encryption key or a number of other things. What happens is most sites proudly state "using PGP encryption," or something similar. Which is not really security at all, but just prancing around saying "we are hiding our private stuff in bank X, bet you can't get it!" And most people using PGP or some such are using it for meaningless data which does not need security.

I feel a big part of this debate is people have some sort of urge or agenda to make all software open. If "security through obscurity is bad" really means "proprietary software vs. open software" then we should skip the debate about security and look at facts about software methods producing secure software.

Those facts for wu-ftp are:
- wu-ftp is open and peer-reviewed
- wu-ftp had a serious flaw
- wu-ftp's flaw was released publicly
- wu-ftp is (was?) not yet patched on most systems

This is a repeating pattern among free software. It has happened more times than I can remember with just the Linux kernel itself. It also happens with sendmail and bind more than I would like to know about. And today someone will surely believe that wu-ftp is secure now that is patched. This is what I call "security after the fact." Which, to me, seems what the open software crowd is more concerned with than "security before the fact."