Slashdot Mirror
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 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!
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.
'There is a Light that never goes out.'
Is this how Linuxtoday was just hacked?
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!
Sometimes it's best to just let stupid people be stupid.
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.
I'm somewhat surprised--but either way it brings the unresolved question of disclosure bubbling to the froth again.
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.
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
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
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.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
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.
Intelligent Life on Earth
My suggestion is that you do instead:
#apt-get install bsd-ftpd
which is a port of the audited OpenBSD FTP server.
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?
-- @rjamestaylor on Ello
Gary McGraw 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.
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 ported to linux.
i just felt that people should be aware that there was more to the story.