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.
Seriously?
'There is a Light that never goes out.'
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.
The fact is, the blackhats have known about this vulnerability for some time, so fix or no fix, you need to be aware of it, so you can disable your ftpd if you think the risk is too high.
;-)
Not disclosing this asap will only give you a false sense of security, and will deny you from making your own risk assessment.
Hell, why do you think Microsoft wants to limit disclosure? To empower the sysops?
I suffer from attention surplus disorder.
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
Well then close the service off. An unuseable service is better than a r00ted server.
It is good to know that it could potentially be rooted. Being ignorant of security holes does not make it secure - no matter what Scott Culp may tell you.
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.
The facts did not change a whit. This is just another in a long train of gaping holes in critical software, which you must have been aware of. Either you never thought to ask yourself, "What if this bug affected a service that I rely upon?" (in which case you were intellectually lazy), or you failed to appreciate the impact it would have (in which case you erred in judgement). It happens, I know, but don't make excuses.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
For uploads, FTP is still probably better, if only because nobody seems to use the HTTP PUT command.
For downloads, though ...
What are the advantages to FTP for downloads (especially anonymous, but also authenticated)? I honestly can't think of any ATM.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Do tell me the other forms of security.
I hear this all the time. "Security through obscurity is bad!" What other forms _are_ there? Passwords and encryption _is_ the same as obscurity. People using this "security through obscurity is bad" argument seem to have another agenda: tearing down IP laws and promoting freedom of information. While IP may be bad, it is a very seperate issue.
How do people claim security through obscurity is a bad thing? Why is it bad? How else does security work? There is physical security or there is abstract/obscure (i.e. encryption) security. What else?
There is also insecurity through ignorance, which seems like a disease in the networked world. It really doesn't matter much if you post the memo on the admin/end-user's forehead if they don't bother to read it. This seems to be the case more than script kiddies finding out before knowledgable admins. After all, where do script kiddies get their info? Same place admins do: Bugtraq. By the time those damn elusive script kiddies on IRC exploit a few holes in nasa.gov, I'm sure at least one knowledgable admin has posted a report to bugtraq. In case you didn't pick up the sarcasm, most script kiddies travel in herds and attack usually obvious "high-risk" sites. If someone knows something before Bugtraq, I'm sure you have very little to worry about. The exploiter is probably a knowledgable cracker and probably has specific targets. If you happen to be a target, I wish you well, but I don't think any amount of Bugtraq info will keep someone determined to get in your system out (hint: There is a whole world of social explotation that is damn near impossible to detect or even be aware of).
Dijkstra Considered Dead
Hmm, when I think of "Security through Obscurity", I tend to think of it in a different way than thought of above. I think of it as keeping the method used to encrypt/secure/hide something secret, thinking that because the method is secret it is secure.
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.
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.
regards,
garc
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.
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.