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