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.'
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.
This raises the question of ethics, is it more ethical to keep quiet about a hole in software that people run / store important data until its fixed, or is it ethical to tell the public in which case the people affected become "more" vulnerable?
Personally, i would rather be told of the hole, and advised to turn off the daemon, as opposed to running the daemon and not knowing about the hole.....some people think ignorance is bliss.....not me. =)
I SURVIVED THE GREAT SLASHDOT BLACKOUT OF 2002!
I'm somewhat surprised--but either way it brings the unresolved question of disclosure bubbling to the froth again.
Plus, its pretty bad since whenever micorosoft gets something like this, people get pissed off if they take more then a weekend on it. Here, they took almost a week longer then RedHat, makes you wonder how long this sploit was in hacker circles, and how long the distros knew about it. Whatever happened to the claims of fast reaction in the opensource industry vs. old-skool business?
This isn't a troll, but an honest question - what tookem so long, and why didn't they just throw it open to end-users to protect themselves (like closing down ftps in worst-case) like is supposed to be standard practice?
I gave wu-ftpd the boot ages ago. I can't understand why people would still trust this buggy, bloated "just asking for trouble" piece of software. There are better alternatives.
PureFTPD (based on TrollFTPD)
ftpd-BSD (port from OpenBSD)
Virtual FTPD (based on ftpd-BSD)
are all good examples of decent alternatives. I've even heard good things about vsftpd.
Some people (myself not included) even consider ProFTPD to be a viable alternative.
How can people still trust software that has had more holes in it then the finest Swiss Cheese?!
Well, I'll bash MS, and I'll bash the GNU and Linux guys for the same thing. Why was this not released SOONER?
The people who would really use the exploit already know about it in their cracker circles, so why are we limiting the public in this knowledge? Just tell us and we'll shut down the FTPs or temporarily switch the access to a different daemon while you write a patch for it.
Again, this is security by obsurity, and shame on the OSS community for trying to hide it!
Zodiac Survey
The attacker must ensure that a maliciously constructed malloc header containing the target address and it's replacement value are in the right location in the uninitialized part of the heap. The attacker must also place shellcode in server process memory.
Color me stupid, but that doesn't sound too feasible for a remote hack. How would you muck with the malloc heap this way? DoS, maybe, but unless there's something I'm missing, not too great for root access. Let me know if there's something I'm missing.
Tim
Using the C language to implement anything else but the lowest-level layers of a system is plain incompetence, all the more when security is involved. The criterium is simple: if there is ANY use of dynamic allocation, you should use a safe language like OCAML, CommonLISP, Mercury, Perl, Python, etc. [Of course, C may be used when *implementing* the dynamic allocation].
-- Faré @ TUNES.org
Reflection & Cybernet
item: the version of wu-ftpd that rh released was a pre-release from cvs. they changed the version number. this bug was fixed in cvs months ago.
item: the securityfocus vuln-help people are supposed to help coordinate vendors & the software maintainers. they sent notification of the bug to the wrong address, so the wu-ftpd developers weren't even aware that there was a bug present until the day the rh advisory went out.
item: there was supposed to be a coordinated advisory put out on dec. 3rd. rh preempted that, causing this nasty confusion.
greg lundberg posted a big explanation of what went on to several mailing lists... it should be on the wuftpd-questions archive, but i don't see it there yet.
also, see the news item at securityfocus about this.
http://www.tuxedo.org/~esr/jargon/html/entry/glob. html
[Unix;common] To expand special characters in a wildcarded name, or the act of so doing (the action is also called `globbing').
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
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.
How dare those RedHat bastards fix a security problem early.
Now you guys are criticizing Red Hat for releasing information too quickly?!
Make up your minds. Either it is a Good Thing to release this sort of information to the public or not. IMO, if CERT is withholding information to the public that just gives a wiley cracker that much extra lead time to perform exploits. Whereas if the info was just released in the first place, at least people could turn their FTP servers yet, or switch to something like pure-ftp, which has yet to be cracked.
I agree with Red Hat on this one. They did people a favor by releasing the information.
No, Thursday's out. How about never - is never good for you?
I looked through the source of Wu-FTPd some time ago, when I was interested in adding support for an encrypted form of FTP proposed in a recent RFC (the protocol never caught on). What I found scared me. Most of the server is one humungous 8000-line C source file which appears to do pretty much everything.
Having quite a bit of experience with the FTP protocol, I expected to immediately understand what was going on, but at first glance, this code baffled me. It's full of pointer arithmetic and chains of if-statements performing mysterious, undecipherable operations on fixed-length arrays. It's not divided into clear levels of abstraction and I had difficulty telling what most functions were supposed to do, let alone what they actually did.
Anyway, I immediately gave up any thought of adding any new features to this godawful mess. Considering all the weird cruft that goes on in that code, it's no surprise to me that people are constantly finding new security holes in it. There are other featureful FTP servers out there; it's hard to see why distributions continue to include a bug-ridden program like Wu-FTPd as default in their distributions.
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
Give me a god damn break. If you had a CLUE about the facts in this case (which include incorrectly addressed email etc) you obviously would not be posting. Why not let the folks whos business this is, CERT, handle the 'punishment', and you go do something useful?
RedHat has CONSISTENTLY done the Right Thing in a number of areas with respect to Linux. Despite a number of chances not to. This endless self-destructive attitude of the linux community, mainly centered with people who have yet to contribute a line of code anywhere I suspect, but who love waving their hand and yelling foul should stop.
Seriously, I'd love to auto-mod down folks who don't contribute jack, but cause endless heartache on endless lists. Recently a flame war errupted when someing claiming to be one of the 10 people in the world who wanted to see the kernel improve came on and said linus should stop maintaining 2.5, despite the fact he'd yet to write a line of code for the kernel.
Taking what trolls like this and the one above seriously undermines things.
The irony is that the linux camp is all for full disclosure, so RH arguably did the RIGHT thing and let us all know of a problem we wouldn't have found out about till later.
This shows you what daemons are auto-started: /sbin/chkconfig --list | grep :on
/sbin/chkconfig --del THING_YOU_DONT_WANT
/etc/ssh2/ssh2d),
#
man NAME_OF_THING_YOU_DONT_KNOW_WHAT_IT_IS
#
get the latest nmap from freshmeat.net.
do this:
# nmap -sS -P0 YOURIPORHOSTNAME
do you see any ports you weren't expecting?
Turn off the services!
Install portsentry + ipchains on a firewall,
or if you don't have more than one box, your
own box! Set portsentry to listen on bind to
catch a lot of automated attackes from a RH6.2
bug. Move your ssh (2.X or greater!!) daemon
to a non-standard port (edit
then set the normal ssh port as a portsentry
tripwire.
Very active attacks right now:
Bind
ftp
finger
telnet
ssh
port 59 (anyone know wtf that is?)
wu-ftpd had an *earlier* vulnerability that
was causing increased scan activity too!
Subscribe to the cert.org mailing list, and
"grep for linux".
you have to take an active role and pay attention
to all security bulletins out there, because
you will literally be attacked within an hour
of bringing up a new DSL/T1 server anywhere in
the wild. I've seen portscans on newly installed
lines in less than 5 minutes!
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
The closed source vendors who are against full disclosure would prefer that the vulnerability is never announced, which would (according to them) allow them to take their time and roll the update into their next service pack release or whatever.
And to the people who suspect some kind of nastiness on Red Hat's part for their early announcement, the individual at Red Hat who claims personal responsibility has already apologized on the private list, and has admitted to erring. The private list has existed for a long time and has worked very well in the past, allowing several vendors to all release fixes at once to a previously unknown vulnerability. It would have worked fine again in this case, except for the mistake by Red Hat.
noah
Sure they put out this advisory before it became knowledge to the NEWS organizations, but the "bad guy" groups have known about this for quite some time. Case in point, my brother wanted to show me some large home-movie mpegs (much to large to email to me), so he gave me an account on his box to ftp them from. Somehow the password that he gave me wasn't right (he must typed it with the caps lock on), so I couldn't get into his machine. He was already asleep by that time, so I couldn't call him up to change it, so just for kicks, I thought it might be fun to see if there was any way to break in. Sure enough, a few well-formed google searches, and I had pages that not only "discussed" this vulnerability, but had tools and scripts (including compiled Windows 9x GUIs for the lazy script kiddie) for download. They were wonderfully useful, and they *worked*.
So, the root of the situation is: 1) Anyone who did NOT know about this hole had been vulnerable LONG before the posting. 2) When told about the hole, but without a patch, any of those admins could then take whatever steps would be needed to keep thier server secure (even shutting ftp down if it came to that).
RedHat was right.
"Your superior intellect is no match for our puny weapons!"
Now, RedHat maybe shouldn't have ever made this "agreement" to pospone patches. Maybe they noticed that people were already making use of this not-so-secret-to-black-hats bug. Or, maybe it was just a mistake... I don't know. I'm just glad I don't have a public wu-ftp server to deal with.
-- these are only opinions and they might not be mine.
HTTP really is all that.
HTTP/1.1 supports, among other things, file resuming via a standardized header (Range:) and pipelining (whereas FTP's control port+data port means n+1 TCP connections). HTTP can give you a file compressed the way you want it - and in the language you asked for - without filename hacks. HTTP's If-Modified-Since: header makes it more cacheable. In addition, most HTTP server implementations are more flexible - they can authenticate against things other than the local account database, and there is a widely implemented standard for HTTP over SSL - HTTPS. CGI is also more pervasive and useful than SITE EXEC.
Let FTP die the death it has so long deserved.
Learn more about security before offering advice:
k .h tml
d vi sory-1223.html
Breaking chroot jail:
http://www.bpfh.net/simes/computing/chroot-brea
Proftpd globbing bug:
http://www.linuxsecurity.com/advisories/other_a
maru
It's definitely not trivial, but...
The basic idea is that you experiment on a local system (in the debugger) to characterize to behavior of malloc()/free() when this bug is triggered.
Once you've done that, you should be able to get free() to overwrite some specific piece of memory by doing a glob operation that succeeds, followed immediately by one that fails, or some such.
Then, you use that building block to work out an attack. It's not exactly rocket science, but it IS more complicated to exploit than a typical security hole.
-Mark
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.
Check out this thread on the wuftpd-questions list:
m =100698257011540&w=2
http://marc.theaimsgroup.com/?l=wuftpd-questions&
/. is irrelevant.
As we are all aware, Wu-FTPd is insecure, buggy, and, for the most part, a thrown together hack. All of you wu-ftpders could eliminate (or at the least dramatically reduce) your problems by using one of the following:
ProFTPd: the ftpd that I prefer most. It was designed with security in mind (wow, rhyme) and its configuration is akin to Apache's.
PureFTPd: a relative newcomer; said to be fairly secure. Based upon TrollFTPd.
If you're an administrator that prefers security over convenience, you may wish to check into secure FTP or simply use SSH to transfer files. Like many "old style" daemons, FTP transmits sensitive data (namely passwords) without any type of encryption applied. Just remember: system security depends only on the competence of your administrator. Most administrators (at least myself and those that I know) refuse to touch wu-ftpd with a fifty foot pole.
Do you like German cars?
Anyone using wu-ftpd has only themselves to blaim if anything happends to their servers. This application has a bug history making Microsoft look like what OpenBSD claims to be. There are many free and secure and certainly more extensible options available, so why distros still stick with wu is beyond my understanding.
Maybe to YOU, how about all the other people who will get nailed when YOUR box is hacked and used in Distributed Denial of Service attacks? How about the emabarassment of discovering your box being used as a drop point for many megs of porn for sexuality other than your own? How about all the webmasters who have to put up with probes (at least) from your box after it catches the latest worm? How about your ISP being notified that you've committed criminal activity against another computer because a cracker cracked you and used your box as a springboard?
If you can't be bothered, take your box of the internet, PLEASE.
Steps to a (more) secure box:
Turning off unneeded services, then firewalling (actually, packet filtering) to allow only known-good protocols is 'defense in depth' - the odds of screwing up in both places the same way are smaller than for either one singly.
Interesting story: I was doing work on a box for a guy who only had *dial-up* access and only used it to send/receive email and browse a little. He was cracked, which I discovered when his netstat wouldn't take the -p option (his version had been replaced after he was cracked, which is common - the crackers replace common utilities with versions specifically written to *not* show their activities on your machine). Ooops - time to reformat and re-install. The fact that you are on a slow link or you are obscure doesn't help much - the script kiddies pick a block of IP addressess at random and scan them all for their vulnerability du jour - if you have it, you're toast.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
If anyone would actually read the CNet article that goes along with this story, you'll see that it was accidently disclosed early. To quote:
"We were releasing some advisories on the same day, and an overzealous administrator pushed this out as well,"
So essentially some sysadmin who strongly believes in full disclosure decided to go against company policy and announce it. He's probably getting reprimanded (perhaps fired) and it looks bad on Red Hat because of a "rebel" employee.
The afformentioned distribution is also unaffected by the following other bugs:
Nimda: IIS 5.0 is not installed by default in OpenBSD
Ping of Death: The Microsoft TCP/IP stack is not loaded by default in OpenBSD
Recent Linux Kernel Bug: OpenBSD unfortunately uses the BSD kernel and the Linux kernel is not installed by default in OpenBSD
As you can see, OpenBSD is obviously the superior operating system, for namely, its lack of features.
Thank you.
I know that we sometimes live with legacy code; fair enough. But I claim that it is entirely inappropriate to write security-critical internet daemons in C!
There are lots of people here claiming that this is caused by sloppy or inexperienced programmers. I think that this is bullshit. Are the authors of wu_ftpd bad programmers? BIND? IIS? perl? telnetd? quake 3 arena? sshd? All of these have had remote overflow (or related) exploits. There are hundreds more... Have you personally ever written a multi-thousand-line network daemon that you know is buffer overflow free? How do you know?
Here is what I say: C the language makes it easy to make the kind of mistake that leads to a remotely exploitable buffer overflow. It is almost as if the language is designed to enable this behavior. According to CERT and others, buffer overflows (and related format-string vulnerabilities, also endemic to C) are the most common source of security holes in UNIX applications (On win32, they are second only to Outlook attachments).
There are only two reasons I can imagine that people would reasonably use C:
Low-level Hardware Access - Fair enough. There are not really any good alternatives now. However, network applications do not need to do low-level hardware access at all.
Raw Speed - Though I believe that other languages are very near to C in performance (http://www.bagley.org/~doug/shootout/craps.shtml) , conventional wisdom says that if you want ultimate speed, use C. However, network applications are not typically CPU-bound, they are network bound. ESPECIALLY FOR THE HOME USER, with a 1.5ghz PC and 5 users per day, this argument is totally silly. Outside the enterprise (where hopefully people can custom tune their software and have people devoted to keeping it secure), there's no reason to need C's speed in a network daemon.
IN A NETWORK APP, SECURITY (SAFETY) IS CRITICAL. That means that all network apps should be written in a language with machine-checked safety. This might mean Java for people who need it to feel like C. (Note that there are several good native code compilers for java, and it has reasonable network support.) In these kinds of languages, buffer overflows and format string vulnerabilities are automatically impossible. Personally, I prefer a more efficient language with stronger safety guarantees: SML. (Ocaml might suit the slashdot audience better) In fact, at the time of the last wu_ftpd remote root exploit, I decided that it was time for me to rewrite my ftp daemon in SML. It took me only 1 weekend to get it working, by myself. It does not support every feature of FTP (especially obsolete things and dubious "features" like SITE EXEC), though it supports plenty for say, the average linux desktop user. Writing code in a modern, high-level language has other benefits too: it is only about 3000 lines, including library code that I wrote to implement MD5 passwords and various other things that I plan to use in other daemons (the core ftp server is only 850 lines). Compare this to wu_ftpd (8000+ lines) and the PAM MD5 password implementation (200 lines). Most importantly, I know that by using a safe language that I have a 100% buffer overflow free daemon. Thus, I can spend more time looking over the code for more subtle security problems, such as possibilities for Denial of Service attacks. (I didn't do much of this, actually, though it is not vulnerable to the ls globbing attack, SITE EXEC, or PAM authentication bugs that have been in other ftp servers.)
If you think this sounds good, you can get my FTP server here and an ML compiler here . (It is just a proof of concept, so don't get too excited!) But what I would rather you do is just listen to my advice, and demand better from your software manufacturer! Linux distributions that want to be secure should be rewriting this kind of software in some modern safe language. It is easy to do, and the results are worthwhile.
which, I might add, I'd never heard of before doing a suitable google search. If you're curious, the NFILE rfc can be viewed at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1037. html. Basically, it sounds like some sort of strange FTP analog (from the glance I took @ the abstract). Publish date was '87, so this is a relatively old protocol, that from the sound of it hit the dustbin of history with a loud "thump!" ;-) (The 'any private ...' bit may be from NFILE's predecessor, QFILE?)
News for Geeks in Austin, TX
Yes, or you could replace both of them with webdav.
I just spent a week playing with WebDAV, investigating it as a possible solution for a customer looking for secure Internet file access. Anyone please correct me if my findings are incorrect.
For the unitiated, WebDAV is the protocol name for the "web folders" feature of IE5.5 and up. I ran it as an Apache module. It was incredibly easy to setup. HOWEVER.. Under WinNT, you can only copy files to and from the web folder, not open or edit them directly. With Win2k and up you can open and edit files directly in the web folder without needing to transfer them to your local PC first, which is much nicer.
The reason I wouldn't recommend it for my customer is that AFAICT the reads and writes on the server side are done with the user and group that the web server runs as. While it does indeed support ACL's, the ACL's are just for the web server protecting the file space in general, and do not maintain the uid/gid of the web-authenticated user down to the file level. It would be sufficient for providing a "common" drive for all the authorized users with no file-level ACL's. You would need to create a new VirtualHost for each file area that needs its own ACL (think home directories).
Imagine 100 users. That would require 100 VirtualHost blocks with independent htaccess files and at the filesystem level, every file and every directory would still be owned by the web server! Not exactly a suitable solution for a client to implent his own in-house version of WebDrive.
In addition, I repeatedly experienced "this operation could not be completed due to an unexpected error" in Windows NT when trying to traverse certain directories of MP3's. If it doesn't work for me in certain situations, it would be disastrous for the customer looking for a "highly available" solution. More like "barely available". I can't architect a solution around something like that.
Having said that, I would love to see a major web archive like ibiblio.org set this up for easy file browsing and access. That would also give the WebDAV team an enormous amount of feedback from a single site, and hopefully iron out more of the issues that keep this unsuitable as an enterprise-class solution.
Intelligent Life on Earth
There's no excuse for running the entire FTP daemon as root. It should start out as "nobody", and upgrade its privileges using a minimal privileged login program. The security checking shouldn't be in the FTP daemon at all.
I have not made an ontology, but it seems to me that nearly all exploits the past few years have been (in decreasing prevalence order)
- data buffer overflow
- string overflow
- filename
.. abuse
A language with safe memory management will eliminate the first two. The third needs a more robust set of filename functions.Its not impossible, or even hard, to avoid these sins in C programming. But, it also isn't impossible or even hard to screw up and commit this sins.
Programmers make mistakes. That is why it is called programming instead of typing. Choosing a language that minimizes the security impact of mistakes makes a lot of sense.
Don't forget about other criteria. You may need the speed that can be had with well written C code. Usually you won't.
I look at my servers. They are all the slowest rackmount machines I could buy from Gateway when I bought them, 800MHz PIII is typical. (They are plural because the have different security policies, not because of load.) They handle things like mail, http, samba, cvs, ldap, the usual suspects for a 100 engineer software firm. They rarely go beyond 5% cpu utilization. I would gladly sacrifice my surplus cpu cycles for slower, safer, services. When they do go beyond 5% it is almost always for a very specific function like the rsync algorithms or blowing backup data over to another box. Make the hot spots of these functions fast, spend a lot of time making them secure. Probably not more than 400 lines of code between them. Let the rest be written in a safe language.
the alarming thing this time is the Linux guys adopting the Microsoft methodology for patching leaks. sit on their ass while boxes get rooted and release the patch when the "agree" to do it. don't tell anyone who might just code a patch into the source themselves. can't have that, can we?
cat
To protect against unknown exploits, there are kernel patches like LIDS . With LIDS, you can enforce any program to only access some files. For instance, you can enforce Bind to only read his configuration files, and nothing else. So even if an exploit is found, your system will be safe.
/home. So it means that if an exploit is found, even with a properly configured LIDS barrier, the attacker can change the content of any customer file. And that's really dangerous. And LIDS can hardly avoid this.
It works amazingly well, and for almost everything on your system.
But does it apply to SSH and FTP? Probably not. When you give FTP access to customers so that they can upload web pages, the FTP server needs read/write access to everything in
{{.sig}}