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.

Re:Nice.

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.

Re:Nice.

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?

Wu-FTP not in OpenBSD

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

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.

Re:I've changed my mind

The script kiddies probably knew about this long before CERT did. This is the major problem with private bug lists for vendors; It gives script kiddies a while to continue exploiting boxes while the vendors prepare patches. I would rather know right away, disable FTP, and do without for a few days, than wait until the bug was fixed before I am informed. Private lists, like all other forms of security by obscurity, are inherently ineffective.

Re:I've changed my mind

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).

Re:I've changed my mind

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

Re:I've changed my mind

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? ;-)

Re:I've changed my mind

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.

Re:I've changed my mind

To paraphrase Keynes:

"When the facts change, I change my mind. What do you do?"

Seriously?

Re:I've changed my mind

When the facts change, I change my mind.

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.

My favorite quote

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!

HTTP vs. FTP

HTTP can't really offer all that FTP does in terms of file transport.

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.

Re:My favorite quote

I simply question the view that HTTP is a simple (and better) replacement for FTP.

For uploads, FTP is still probably better, if only because nobody seems to use the HTTP PUT command.

For downloads, though ...

• both require a new connection for each dir listing or file transfer - except HTTP/1.1 which can reuse a connection. HTTP wins.
• FTP requires an additional TCP connection for the control info. More setup and teardown cost. HTTP wins.
• 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.
• HTTP can use auth methods other than plaintext, and can easily have different sets of auth'd users in different directories (without using Unix permissions, which can occasionally get clunky, or you can use Unix permissions if you prefer). FTP only has user/password/account auth, and nobody uses the "account" part anyway. HTTP wins.

What are the advantages to FTP for downloads (especially anonymous, but also authenticated)? I honestly can't think of any ATM.

CERT and private lists

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.

Whats ethical?

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. =)

Re:Another globbing bug?

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

Re:Another globbing bug?

Learn more about security before offering advice:

Breaking chroot jail:
http://www.bpfh.net/simes/computing/chroot-break .h tml

Proftpd globbing bug:
http://www.linuxsecurity.com/advisories/other_ad vi sory-1223.html

maru

People still trust Wu-ftpd?

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?!

how would you exploit this, though?

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

Stop using stupid C language

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].

Re:Stop using stupid C language - good point

It is a good point. Poorly made, but there is a good point hiding in there. I see the article has atracted 6 flame replies and a -1 troll before I read it.

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.

more to the story

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 [landfield.com] archive, but i don't see it there yet.

also, see the news item [securityfocus.com] at securityfocus about this.

Know what you're doing.

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.

Shame

How dare those RedHat bastards fix a security problem early.

Hypocrisy Detected!!!

Now wait a minute. Here on /., MS gets slammed because they want bugtraq and whoever to wait before they publicize a security hold until a fix can be reasonably made.

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.

Re:Hypocrisy Detected!!!

Tip for MSCEs: Samba and SSH will allow you to remotely administer a Windows network better than any Windows tool.


Actually, IIS does a pretty good job of letting *everyone* remotely administer your Windows system.

No surprises here

Wu-FTPd has had a long history of security holes. It's practically the BIND of FTP servers.

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.

Security must-dos for RedHat

This shows you what daemons are auto-started:
# /sbin/chkconfig --list | grep :on

man NAME_OF_THING_YOU_DONT_KNOW_WHAT_IT_IS
# /sbin/chkconfig --del THING_YOU_DONT_WANT

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 /etc/ssh2/ssh2d),
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!

port 59 is the "well-known" port for "NFILE"

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 [ohio-state.edu]. 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?)

ironic..

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. :-/

To those who would cry "hypocracy"

There have been a number of posts here claiming that the Linux vendors are being hypocritical by claiming to support full disclosure while maintaining a private list for the coordination of announcements regarding such security issues is this. However, they are missing the point. This list is not against full disclosure in any way. It is simply a way for vendors to coordinate their fixes before the exploit is widely published. At no point are the vendors discouraging the vulnerability's publication. They are merely delaying the announcement so they can coordinate the availability of their updates.

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

Tiny Violins

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.

Regarding disclosure...

As a security bug hunter myself, I know that the sooner you disclose the sooner it gets fixed. The more serious the hole, the sooner it should get fixed. period. 2 weeks ago, I published an alert [securityfocus.com] on a bunch of website security holes, including microsoft.com. Knowing how ms reacts to disclosure, I didn't disclose the specifics on microsoft.com's site, but I did on the others. Guess what? The hole on microsoft.com is still not fixed, while most other sites have moved to fix their holes. Now, this hole also affect thousands (if not millions? ) of sites, but it seems to require disclosure to get things moving.

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.

WU-FTPD maintainer ain't happy...

Check out this thread on the wuftpd-questions list:

http://marc.theaimsgroup.com/?l=wuftpd-questions&m =100698257011540&w=2 [theaimsgroup.com]

Go with something more secure.

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 [proftpd.net]: the ftpd that I prefer most. It was designed with security in mind (wow, rhyme) and its configuration is akin to Apache's.

PureFTPd [sourceforge.net]: 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.

Anyone using wu-ftpd...

Anyone using wu-ftpd has only themselves to blaim if anything happends to their servers. This application [wu-ftpd.org] has a bug history making Microsoft look like what OpenBSD [openbsd.org] claims to be. There are many free and secure [netbsd.org] and certainly more extensible [proftpd.org] options available, so why distros still stick with wu is beyond my understanding.

C lang remains inappropriate for network daemons

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 [inria.fr] 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 [sourceforge.net] and an ML compiler here [sourcelight.com] . (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.

Why is a FTP daemon running as root?

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.

Can kernel security patches do something against t

To protect against unknown exploits, there are kernel patches like LIDS [lids.org] . 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.

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 /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.