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.

People still trust Wu-ftpd?

[Azar]

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

Why use Wu-ftpd

[niekze]

I'm not a security expert by any means, but...here is my list of horrible things to run:

1. sendmail
2. bind 8
3. Wu-ftpd.

There are replacements for each. Djbdns will give you $500 (IIRC) if you find an exploitable bug in their code. Proftpd, lukemftp, and the bsdftpd are all *much* better replacements for Wu-Ftpd. Sendmail...i can't remember, but there are replacements.

Nevertheless, bind should be run in a chroot jail. Doing things like that makes a bind hole useless. Please uninstall Wu-ftpd and use a replacement. Finally, if you don't need to run it, DON'T!

Re:I've changed my mind

[Anonymous Coward]

sorry but the script kiddies had this for weeks now.

Why do you have to be so pompus to think that you are told about an exploit before a baddie has it...

a BADDIE uses it that's how it is discovered nimrod.

more to the story

[Phexro]

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.

Re:Please Explain, dude(ttes)...

[Anonymous DWord]

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

Security must-dos for RedHat

[Hoonis]

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!

Re:Wu-FTP not in OpenBSD

[bigbadwlf]

Wu-FTP is not included in all major Linux distributions.
The latest Slackware comes with ProFTPd.

Tiny Violins

[gnovos]

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.

Re:I've changed my mind

[Pinball Wizard]

Please, either disable your service or use your firewall to block port 23. You don't need the fix to do that much. Inform your users that the site is down until a fix is made. Beats having to reinstall your whole OS, right? Who's to say there aren't crackers out there who have access to the CERT list anyway?

If you can't wait, you can probably get pure-ftpd [sourceforge.net] going without too much trouble. Its been written from the ground up with security in mind, and so far no one has found a remote exploit.

Jumping the smoking gun.

[karlitoX]

I find it hard to blame RedHat too much after this post to a publicly archived forum:

Date: Mon, 19 Nov 2001 12:49:47 -0700 (MST)
From: Vulnerability Help
To: bugtraq@securityfocusHeya all,

The SecurityFocus Vulnerability Help Team is in the process of notifying vendors of a remotely exploitable problem in WU-FTPD .
[snip]

I must admit, I simply filed this in my todo list, but I suspect anyone who really wanted to know what was fixed could have found a patch or at least a patched version before the advisory release date.

Re:Another globbing bug?

[gclef]

Well, unfortunately, the definition of "moron" is a bit of a moving target. Something that was fine yesterday may not be such a good idea today (this situation's a great example of that).

For the most part, the general canon of "don't run things you don't absolutely need, and keep the ones you need up to date" will take you pretty far. If you can prevent your machine from accepting incoming connections (ipchains/iptables/ipf/whatever, assuming you're not running a server from your "personal use" box), that helps a lot.

Regarding disclosure...

[slashkitty]

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.

Re:more to the story

[Sentry21]

the wu-ftpd developers weren't even aware that there was a bug present until the day the rh advisory went out.

Come on, this is WU-FTPd we're talking about here. EVERYONE is aware there's LOTS of bugs. It's a given.

What you should have said was 'the wu-ftpd developers weren't aware of this bug'.

I mean, really, every time I bash WU-FTPd, someone tells me that 'WU-FTPd is no worse than proftpd'. C'mon guys, even if ProFTPd is as bad, at least it's not incredibly well known for being as bad. Let's pick a decent FTP daemon and stop defaulting to crap.

--Dan

Re:Another globbing bug?

[bad-badtz-maru]

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

Here's how...

[mbessey]

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

Re:Wu-FTP not in OpenBSD

[spectral]

Mandrake (at least 8.0, and I assume 8.1) also comes with ProFTPd instead of WuFTPd.. though there's an option to use Wu instead, pro is the default.

WU-FTPD maintainer ain't happy...

[MelloDawg]

Check out this thread on the wuftpd-questions list:

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

Or go with WebDAV!

[marick]

Yes, or you could replace both of them with webdav.

WebDAV( IETF RFC 2518 ) is a series of extensions to HTTP that give a lot of functionality such as Access-Control (ACL), Version support, all over a simple HTTP connection (and yes, HTTPS is quite supported). Check it out at http://www.webdav.org

Go with something more secure.

[Scoria]

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.

Re:Another globbing bug?

[fanatic]

I run my own box for personal use, and learning anything more than basic security takes more time than it's worth.

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:

1. issue netstat -apn (adjust for parms allowed in your netstat, but if -a doesn't work, get a new one; if -p doesn't work and you're running a recent version of Linux, you've probably *already* been cracked). Understand every single tcp or udp entry. Turn off any you don't need.
   
   
2. set up a firewall on your machine. Deny all incoming connections by default, then permit only the protocols you need from the endpoints you need to permit them from. For example, I permit http from anywhere. I permit ssh on my home box only from the outer address of the firewalls at work - and this is a good thing because ssh at one point had a hole, so I'd cut my vulnerability way down.
   
   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.
   
   
3. if you're using Linux, Bastille Linux [bastille-linux.org] is a useful script (or set of scripts) that will help you secure your machine and teach you about the process at the same time.
   
   
4. Subscribe to a security mailing list or two (CERT and Bugtraq are good). When you see something you're using there, fix it.
   

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.

Re:Nice.

[m3000]

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.

Re:Debian doesn't have many defaults

[xanadu-xtroot.com]

Although I can't speak for a Debian install (I've only exposed myself to RPM based distros so far), this isn't totally corretct by any means.

There IS a "default" set of packages installed. You have the option NOT to install them (or remove certain things later, of course). If one just does a "recomended" install (or whatever), there is default packages enabled. The big difference is a lot folks (read: package installers) that have gotten there heads screwed on a little better now and VERIFY what Servers you're enabling and if you even want them INSTALLED at all. Very nice...

Sorry to nit-pick, but I thought I'd point that out.

Re:Ok - What does this attack LOOK like?

[Geekboy(Wizard)]

Look at the BUGTRAQ advisiry. ;-) http://aris.securityfocus.com/alerts/wuftpd/ [securityfocus.com] is quite useful. It looks like it's a run-of-the-mill buffer overflow. There are currently no IDS sigs that can detect it (but I'm sure that will change as soon as I post this.) If you can, disable anonftp access. If not, look through the log files for an extreamly long command. (The description shows 60+ 'a' in a row.)


This is very similar to an exploit discovered about 4 months ago. Why didn't the Wu-FTP people check to see if they were vulnerable?

Re:HTTP vs. FTP

[statusbar]

Mac OS-X iDisk uses WebDAV to full-on mount remote filesystems via HTTP/1.1 - Everyone who owns OS-X has a free iDisk account.

Microsoft Outlook (not express) can use HTTP/1.1 instead of imap for remote message folders.

IE has WebDAV support as well.

--jeff

Re:No surprises here

[fusiongyro]

There are solid competitors for all of these.

ftpd: Proftpd wins, hands down. Configuration is like Apache except less crufty. It's modular, and pretty secure too (I can't remember hearing of any major security holes). Some people who use it: ftp.gnu.org [gnu.org], download.sourceforge.net [sourceforge.net]. Enough said. www.proftpd.org [proftpd.org].

bind: bind 9? I can't really think of a replacement except DNScache [cr.yp.to], and I've never used it. I have no idea if it's better or worse or just weaker.

sendmail: I hear qmail [cr.yp.to] is extremely good, if you don't mind DJB's bizarre lack of license (also applies to DNScache). Qmail purportedly runs Yahoo! Mail [yahoo.com] among others. Otherwise, the only other alternative I can think of is exim [exim.org], which is designed to be easier to configure and simpler IIRC.

Next time, post some links or something. Sheesh.

Daniel

Re:I've changed my mind

[ethereal]

Security provided by passwords and encryption are based on shared secrets (or for public-key cryptography, mathematical properties of prime numbers). The only thing that has to be hidden is the secret, which cannot be determined by an attacker, even with knowledge of the algorithm, in less time than it would take to brute force guess the secret. Security through obscurity is more of the case where your protocol itself is broken, so that you must keep both the shared secret and the protocol as well secret. The reason that this is so much less secure is because there are an infinite variety of shared secret passwords to choose, but only so many protocols. Once a broken protocol is cracked it is cracked for everyone that uses it; once your password is guessed it only affects you.

So in each case there is something that must be protected from being found out; but the chances of the thing being found out and the consequences if it is found out are vastly different.

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

[StandardDeviant]

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

Re:I've changed my mind

[Jahf]

I think you misunderstand the phrase "security through obscurity is bad" (STOIB). Password protections and encryption are not obscure ... obscurity means no one (supposedly) knows they exist. Everyone can know that I -have- a password protection scheme on my computer, it doesn't mean that they actually know what that password is. My password then is (I hope :) "obscure", but my security scheme is not.

Similarly, if I were to hack my Linux box to store encrypted passwords in an "unknown" file (say, /etc/bogus) that was readable by anyone, but no one knew what the information in the file was, that would be STOIB. However, if I put it in a standard location (/etc/shadow), but make sure that only "root" can read it, that is not STOIB.

The phrase was coined to indicate a scheme where something is -not- encrypted/whatever and instead is considered to be "secure" because "no one knows about it" (ie, it is "obscure").

Examples of this:

• posting sensitive documents on a web server that has no links to the URLs for those documents and then assuming that no one can get them because no one knows about them.
  
  

  "security through obscurity" -is- bad here ... with the tools at hand (search engines and robot exclusion files as an extremely simple example) people -will- find this information at some point.
  
  

• creating a user account with an unusual name and no password and assuming that no one will be able to log in as that user because they don't know the username
  
  

  As with the previous example, security through obscurity again is bad here, but only in the light of "bad" meaning "stupid", not necessarily evil.
  
  

• writing software that has a hole in it, discovering the hole but not disclosing the fact that it exists for the purposes of keeping the software "secure" instead of patching the hole and disclosing the hole's existence to encourage people to patch their software
  
  

  This is the arena where the "bad" in "STOIB" is "evil" or at least damaging to other people. In this example, you as the software author -caused- the hole in the other person's system, you should be the one to fix it or at least not prevent other people from fixing them.
  

"STOIB" only involves Intellectual Property if you claim that the only way to combat STOIB is to be Open Source and this is definitely the hardline. However, closed systems can still issue patches and disclose security issues without giving out their IP.

SuSE Announcement with download information

[riggwelter]

You can read SuSE's announcement about this here [linuxtoday.com], along with details of how to get updated SuSE packages.

Re:I've changed my mind

[Garc]

If you consider a safe to be secure, even when its location is known, then it really isn't security through obscurity. Don't get me wrong, the fact that its location is unknown helps. Keeping something secret can help, but only if it would be secure even if it wasn't a secret. An example of this is the RSA-like encyption that the NSA developed years before it was discovered by the public.

regards,
garc