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.
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?!
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!
Chaos, Mayhem, and Destruction: Not
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.
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
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!
Wu-FTP is not included in all major Linux distributions.
The latest Slackware comes with ProFTPd.
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!"
If you can't wait, you can probably get pure-ftpd 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.
No, Thursday's out. How about never - is never good for you?
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.
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.
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.
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
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.
Check out this thread on the wuftpd-questions list:
m =100698257011540&w=2
http://marc.theaimsgroup.com/?l=wuftpd-questions&
/. is irrelevant.
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
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?
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.
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.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
Look at the BUGTRAQ advisiry. ;-) http://aris.securityfocus.com/alerts/wuftpd/ 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?
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
ipv6 is my vpn
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, download.sourceforge.net. Enough said. www.proftpd.org.
bind: bind 9? I can't really think of a replacement except DNScache, and I've never used it. I have no idea if it's better or worse or just weaker.
sendmail: I hear qmail is extremely good, if you don't mind DJB's bizarre lack of license (also applies to DNScache). Qmail purportedly runs Yahoo! Mail among others. Otherwise, the only other alternative I can think of is exim, which is designed to be easier to configure and simpler IIRC.
Next time, post some links or something. Sheesh.
Daniel
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.
Your right to not believe: Americans United for Separation of Church and
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
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:
"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.
As with the previous example, security through obscurity again is bad here, but only in the light of "bad" meaning "stupid", not necessarily evil.
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.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
You can read SuSE's announcement about this here, along with details of how to get updated SuSE packages.
Listening for the sound of the coming rain...
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