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.
Have a nice day!
Someone at RedHat's got their business thinking cap on.
Release a fix that no one else is able to yet and tell the world how to exploit the hole.
Crush the competition while they sleep.
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!
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.
'There is a Light that never goes out.'
Is this how Linuxtoday was just hacked?
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!
Sometimes it's best to just let stupid people be stupid.
just another reason why red hat rocks!
Say it isn't so. A bug that potentially exposes thousands or millions of machines on the net to root access?
It's not suprising that Red Hat would do such a thing.
What no snide comment like when a MS exploit is released?
If this was MS, they wouldn't have told us.
etc.
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.
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. =)
I SURVIVED THE GREAT SLASHDOT BLACKOUT OF 2002!
Isn't the whole idea of CERT to prevent somone from leaking out potential dangerous information before everyone is ready to address it? Even if there's a hole - the relative breadth of the knowledge is going to be limited until a public release - and if no one else has caught up yet . . .well then thats bad.
I would comdem RH - but I use their products and I have Wu installed on some of my systems (They're all internal - so don't even think about it). I'm glad I'll have the fix.
\Drew National Data Director, John Edwards for President
Is redhat becoming the MS of Linux distros? That isn't very cool of them to release early. I am sure they were under no obligation to wait but it certainly doesn't seem "polite".
There\'s no place like ~
AIRC, this type of exploit has been the bane of WuFTPD's existance; one of the reasons I switched to ProFTPD some time ago. Much better security history.
Besides; if you're running a public FTP and it's not in a chroot jail, you are a moron anyways.
--
I Hit the Karma Cap, and All I Got Was This Lousy
The guys at Red Hat sure are jerks. I guess you can always depend on companies to look out for number 1 first, and screw everyone else whenever possible!
IIRC, there was a security hole almost exactly like this one in several other FTP servers. Why didn't Wu-FTP (and the distro's) evaluate the code for it then?
Business is business.
if you have a clue you can have the fix now.
download the sources and install. simple and effective.
Hiding the fact there's is a security flaw only gives the black hats that much more time to use the exploit un-noticed.
It's time to thow out the "leaders" in this industry and start replacing them with men and women with scruples.
Do not look at laser with remaining good eye.
Am I the only person thinking that strategically placed "dumb coding mistakes" might be the real story behind Magic Lantern?
Tarsnap: Online backups for the truly paranoid
I bet that this is how MS feels when people disclose their security holes before a fix.
You should be using ProFTPD anyway.
My god, the security history of wu is pretty bad. I wish vendors would ship default network services with an eye towards proven servers that were designed with security in mind.
Wu-ftp/BIND/Sendmail does NOT make me confident.
And quit carping on RedHat, probably just an error, and this bug was reported to ALL the vendors some time ago.
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?!
Slackware is conspicuously absent from the list, is it not vulnerable? Or just not listed?
The title brought back a question I've had for a while:
the vulnerability: Wu-Ftpd File Globbing Heap Corruption Vulnerability
I've never been able to figure out in laymans terms, much less technical terms WTF globbing is?
Oh, and while smarter people than I are explaining...the quote at the bottom (the one I see)...what is a Vegemite?
Ever since that Men at Work song, I've wondered.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
Further hipocracy on slashdot....
./ blasts MS whenever they try to keep a known exploit quiet for whatever reason, but then goes ahead and blasts Redhat for spilling the beans.
I thought the whole point of OS was so that you can make changes/fixes yourself? I'd rather go a week without a distro patch, then not know about the exploit at all. At least then i can disable the daemon, or impliment a kludge fix.
-Chris
--an unbreakable toy is useful for breaking other toys--
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
wow.... /. running a story only 1 day after the vulnerability was announced?? :)
this is hard to believe.
-- audiowhore
FUCK CERT and their private list. People deserve to know this stuff when it happens.
Well, I'll bash MS, and I'll bash the GNU and Linux guys for the same thing. Why was this not released SOONER?
The people who would really use the exploit already know about it in their cracker circles, so why are we limiting the public in this knowledge? Just tell us and we'll shut down the FTPs or temporarily switch the access to a different daemon while you write a patch for it.
Again, this is security by obsurity, and shame on the OSS community for trying to hide it!
Zodiac Survey
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
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].
-- Faré @ TUNES.org
Reflection & Cybernet
while we are on exploits,
Many implementations of ssh version 1 are vulnerable to a buffer overflow as well. Its a vulnerability in the protocol not the implementation. Last I checked (sunday), debians version of OpenSSH 1.2 from security.debian.org was still vulnerable. Though this is all speculation because no public exploit has been released. (there are exploits around though)
see bugtrack from weeks ago
metric
On the one hand, I can see Redhat getting into problems with people all over for un-leveling the playing field, breaking a gentleman's agreement with CERT, etc.
On the other, this could easily and very vocally show RedHat, true or not, to be a good OS if you want to avoid security vulnerabilities. FUD victims could be saying to themselves, "These other guys sit on their hands for over a week?? I'm going to go with redhat!"
Microsoft social engineers news stories like this all the time. Single examples that Lemmings treat as a global sample of productivity, security, programmers' skill, or whatever other wonderful thing the company wants to tote.
"Look at me, I invented the stove!" -- Ben Franklin
Interesting. On my computer proftpd is the ftp deamon of choice. Granted, this is slackware, which is arguably not a major distro, but Mandrake 8.1 uses it as well, and surely Mandrake is a major distro? They are the most popular, after all!
In Soviet Russia you dant have to put up with these crappy jokes
Not Slackware.
On Slackware, there is no wu_ftp, there is no pam, there is no Vixie crond.
And there are very few security advisories.
Why use wuftpd when it's so trivial to install proftpd (which is, incidentally, also easier to configure)? wuftpd is dangerous to run because it's so patched as to be in the same state BIND 8 is in. Honestly, just because it's the "default" doesn't make it acceptable to run a patchwork server. That's about as dangerous as running a Microsoft server just because it's "industry standard" (which isn't true anyway).
And just as an aside, I respect RedHat for preemptively notifying people, H4XX0R5 included. If Apache were to have a horrible root-access-blows-up-your-site kind of hole discovered, I'd want that kind of incentive to upgrade soon. It's better than saying "There's a hole, we're working on fixing it, just wait and hope that someone doesn't figure it out from our context clues".
"Your mouse has been moved. Windows 95 must be restarted for the change to take effect."
RedHat's 'Early Disclosure' isn't so early to any
crackers who already knew about the hole.
The sooner these things are revealed, the sooner people can switch to more secure alternatives.
The only sad part is that RedHat is apologizing for spilling the beans.
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.
Did RedHat breech trust with CERT? There was an exploit, sent out to vendors, along with an agreement not to leak it until the 3rd.
If there was a formal agreement not to release the information ahead of schedule, should this not be seen as a mark against RedHat?
Unfortunately, there is only one punishment I can see for this. RedHat should be removed from the mailing list for a specific amount of time, but not permanently.
The biggest problem I see with that is that it would hurt the customers, which is what we don't want.
Does anybody else have an idea of a suitable remedy?
I can't say that I don't give a fuck. I've just run out of fuck to give.
For what it's worth.
Check it!
"Your mouse has been moved. Windows 95 must be restarted for the change to take effect."
a) install a secure by default OS such as OpenBSD
b) LEAVE FTP disabled
c) LEAVE Telnet disabled
d) ENABLE SFTP if you need an FTPish connection.
Live happy and don't end up like LinuxToday.com LOL
Trolling is a art,
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.
Linux Today's web site was defaced just a bit ago. may be coincidence or it may be the same hole.
What annoid me is that I read the warning on this and I could not make heads or tails what the actual cause of the hole was. And I am a programmer!
Security warning by obscurity?
"Trademarks are the heraldry of the new feudalism."
How dare those RedHat bastards fix a security problem early.
Slackware ships with ProFTPd, if i remember correctly...
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.
Do all hackers notify CERT first? (How many quiet hackers already found this one?)
Once a company has a fix they owe their customers that fix. Anything less is a compromise of their customer's security and risks tarnishing their trust. Yes, getting a fix out first does matter.
Red Hat did the right thing. If your distro has not put out a fix yet, are they working fast enough? (You think there were no script kiddies out there before Red Hat "broke the news?")
--- -- - -
Give me LIBERTY, or give me a check.
It disturbs me that a formal process of keeping newly discovered vulnerability information from the public seems to be becoming the norm. I would feel much safer if we were informed right away of a known remote execution vulnerability, so that we can assess the risks ourselves, and make the appropriate decision as to whether to disable the service, or switch to a different implementation.
I just know that the powerful interests, not just the federal government, but also foreign governments and corporate espionage types, become aware of these things, and likely have crack teams of dedicated crackers to rapidly turn out an in house exploit.
Asymetric information is inequitable, giving an inevitable advantage to the elite in the know.
Lack of knowledge is powerlessness.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
This is rediculous... the above post is actually an interesting example and a pratical demonstration of security threats. You guys sit and compain about how everyone is so clueless about security issues, then when someone posts an educational example of a security problem, it instantly gets modded into oblivion.
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!
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.
Intelligent Life on Earth
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
If I was a teacher I'd not only have given you an A+, but no doubt been so turned on I'd invite the whole class to squack on me. If the ponytailed compufags who run this site hadn'y IP banned me for bringing the truth to Slashdot, I'd be posting under my real nick. As such, just know that you have my praise! Salut!
Egg Troll
any decent os, whether it is linux, *bsd, BE, Windows, or whatever can be made secure if you actually take the time to set it up properly.
i know it's tempting for all the [insert your OS of choice] zealots to waive their flags when another OS becomes known to have a security exploit. but for fucks sake, just because wu has a hole in it, doen't mean that the entire OS is scrap.
oh by the way -
SNORT is a NIDS (network intrusion detection system) that could help you detect and prevent a good deal of network attacks. IIRC, it has some windows plugins too.
DEMARC is a web-based console for SNORT, plus a pretty good host/service monitor.
--- sig moved for great justice.
FULL DISCLOSURE is a must in my opnion. If the "good guys" know about a vulnerability, the "bad guys" know or will know soon. Sitting on these announcements is shite. Let me know my 14 FTP servers are vulnerable. I don't care if a patch is available or not. At least I know and can relate this risk to my management. I'll let them decide what we should do (to include killing the servers until a patch is available or moving to an alternative).
SHITE. The "security community" scares me on this one. They chose to let a remotely exploitable (root?) vulnerablity ride for a week. A WEEK! Unbelievable!
I'm glad Redhat made this "mistake".
3cx.org - A truly bad website.
And this isn't an easy vulnerability to exploit. If you have a look at the credits for its discovery, you'll see that it has been found before, and was actually deemed non-exploitable at that time. Here is the description of it from the advisory:
Alex.
Finally, some real news for nerds on this turd of a site. BTW, Jaime you're a cockgnome for thinking that IP banning me can keep me down. It only encourages me. I know you're just jealous because I wouldn't fist you last night, but this is such a juvenile way to act.
Incompetence? You sir, are an idiot.
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!"
Or use a read-only, anonymous ftpd like publicfile and avoid getting owned.
We have things like sftp-server for authentication and uploads. There are very few legitimate reasons to keep using ftp for uploads. Are you still using telnetd too?
Hands in my pocket
Proftpd hardly has a stellar security record of its own. Google will quickly verify that statement.
noah
From a Bugtraq post by Mark Canter :
Generic patch against globc.c for:
Subject: Wu-Ftpd File Globbing Heap Corruption Vulnerability
-- SNIP --
--- glob.c.orig Sat Jul 1 14:17:39 2000
+++ glob.c Wed Nov 28 00:43:38 2001
@@ -298,7 +298,7 @@
for (lm = restbuf; *p != '{'; *lm++ = *p++)
continue;
- for (pe = ++p; *pe; pe++)
+ for (pe = ++p; *pe; pe++) {
switch (*pe) {
case '{':
@@ -314,11 +314,19 @@
case '[':
for (pe++; *pe && *pe != ']'; pe++)
continue;
+ if (!*pe) {
+ globerr = "Missing ]";
+ return (0);
+ }
continue;
}
+ }
pend:
- brclev = 0;
- for (pl = pm = p; pm = pe; pm++)
+ if (brclev || !*pe) {
+ globerr = "Missing }";
+ return (0);
+ }
+ for (pl = pm = p; pm = pe; pm++) {
switch (*pm & (QUOTE | TRIM)) {
case '{':
@@ -352,19 +360,18 @@
return (1);
sort();
pl = pm + 1;
- if (brclev)
- return (0);
continue;
case '[':
for (pm++; *pm && *pm != ']'; pm++)
continue;
- if (!*pm)
- pm--;
+ if (!*pm) {
+ globerr = "Missing ]";
+ return (0);
+ }
continue;
}
- if (brclev)
- goto doit;
+ }
return (0);
}
@@ -416,11 +423,10 @@
else if (scc == (lc = cc))
ok++;
}
- if (cc == 0)
- if (ok)
- p--;
- else
- return 0;
+ if (cc == 0) {
+ globerr = "Missing ]";
+ return (0);
+ }
continue;
case '*':
--sam
Any technology distinguishable from magic is insufficiently advanced.
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.
sorry bout that. FTP lives on port 21, not 23.
No, Thursday's out. How about never - is never good for you?
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.
Wu-FTPd is in the Debian package lists, but it is not the default FTP daemon. The default is a piddly little thing that only allows users to log in. It's quite functional, but bare-bones, and likely very secure.
# ant-get update
# apt-get install proftpd (or ftpd)
And you can rid yourself of wu-ftpd on Debian.
--Dan
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?!
OK, so now I know that you've gone back to the previous MS security story, searched out the identities of the (many) people critical of MS's (lack of) action, and compared them with those criticising Red Hat this time round. Care to provide some stats on the correlation?
Or perhaps you're making the same mistake of thinking that Slashdot (or Shashdot minus you)is a monolithic entity, capable of only one opinion on any subject. It's not.
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.
There's a user here on slashdot (sorry I don't remember their name) who used to have the signature "wu-ftpd -- Providing Remote Root Access since 1994".
Having been vicimized in the past, I'm now running ProFTP in the few places I need FTP at all.
If I could find a secure and free-as-in-beer method to provide upload access to some Windows-using folk, I'd bag FTP entirely.
This page accidentally left blank
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
By "default", almost nothing is installed, so ftpd is not the default FTP daemon. There is no default FTP daemon. You install things when you want them.
"The price of freedom is eternal vigilance." - Thomas Jefferson
I said (nt)
...Linux is (or maybe GCC).
Regardless of whether you think C is a good language for high-level applications (I don't), there's nothing wrong with the C language, as such.
This bug is the result of a poor implementation of malloc() and free(). Passing an invalid pointer to free() shouldn't corrupt the heap.
It's not impossible to write a C implementation that's immune to the vast majority of these problems.
-Mark
They came out *before* anyone else, so quit whining. Bash on Debian or someone deserving of it.
I just found one of our servers (which I did not have primary responsibility over) was running the latest version of wu-ftpd... so, what does one of these latest attacks look like (don't say "liuxtoday.com")? How could I spot an attempt in /var/log/messages?
-- @rjamestaylor on Ello
Hello, it doesn't belong here, but, as the slashdot authors *rejected* the story:
2001-11-28 23:52:31 2600 lost the appeal (articles,censorship) (rejected)
The news is just in, 2600 lost the appeal. Nothing more is known. Furthermore, the felton countersuit was thrown out. http://www.2600.com/news/display.shtml?id=852
It is a dark day.
They wrote pine. They wrote imapd. They wrote wu-ftpd. :-)
Have you guys EVER looked at the source of these bloatware products? It's a hell of a mess! If you are concerned about security, NEVER EVER use anything that comes from Washington. Neither Redmond nor UW.
If you have any job or school on your resume from around Seattle, you're carreer as a security specialist is doomed! >:-|
Check out this thread on the wuftpd-questions list:
m =100698257011540&w=2
http://marc.theaimsgroup.com/?l=wuftpd-questions&
/. is irrelevant.
Well, speaking as an above-average computer user but not super-geek, WTF else am I supposed to use?!
FTP keeps all my directory structure intact, and my client of choice has great synchronizing and replacing features.
At the moment I'm working on a giant web project for a company whose name rhymes with a fatty baking product, and everything has to go through an insanely convoluted Web-based interface. With FTP I could just drag the root folder into the upload window and say "replace only files changed today" without having to go into 12 different folders and sub-folders and check off individual files. Granted, that's a problem on their end, but it's annoying as all fuck.
It doesn't mean much now, it's built for the future.
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
Well, we all know what happens when you run wu-ftpd. You get owned.
Its not really any administrators fault, we have learned not to blame people for being stupid.
Wu-FTPD providing root shells since its conception.
Jesus, when are these guys going to really do an audit. Not just keep patching it up when the breaks become known.
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?
even though it was a personal mess-up on the part of an employee, i'm really damn glad i found out about this exploit today. we've had several linux machines here get hacked into this week (older mandrake, RH 6.1, 6.2, and 7.1). the common denominator in all cases is that they were running wu-ftpd and it was open to the outside world. we'd been scratching our heads real hard since monday and now it all makes perfect sense. now everything's either updated or closed off. had we not known until dec 3, how many more machines would we have to clean up while not knowing what it was we needed to fix? i understand wanting to coordinate announcements and patches while minimizing advertising of exploits, but if something is actively being exploited, admins _need_ to know and need to know _as_soon_as_possible_. even if we can't fix wu-ftpd, we'd at least know we need to make sure it's turned off.
tim
hiding in shadows / i hear you coming closer / you will explode soon -- a quake haiku
Anyone using wu-ftpd has only themselves to blaim if anything happends to their servers. This application has a bug history making Microsoft look like what OpenBSD claims to be. There are many free and secure and certainly more extensible options available, so why distros still stick with wu is beyond my understanding.
For some reason, a few minutes after this article was posted on Linuxtoday, their servers went down.
Ok, maybe HTTP/1.1 isn't quite as good as you might want, but if you add in WebDAV, it becomes an incredible replacement for FTP. And CVS. And NFS...
WebDAV servers support (by default) Locking of files, Put of files, PropPatches of custom properties, PropFinds of those custom properties,Moves, Copies, and Delete. Plus Get, Put, Head, etc. that HTTP/1.1 provides.
Furthermore, there are standards defined for:
Furthermore, MANY clients support saving and locking of files over WebDAV. In particular:
Microsoft Web Folders uses a WebDAV server as a file system and ships with Win 98 +
Mac OSX has WebDAV support built into the File System
Several Open Source Developers are working on a quite-functional Linux WebDAV file system that you should check out.
Adobe Photoshop 6.0 does saving over WebDAV. So does Macromedia's Dreamweaver UltraDEV. So does Microsoft Office. Many others do as well.
Mozilla's Composer WILL HAVE WebDAV support (eventually, see bug #13383)
Wish to try it out? Got apache? A level 2 DAV server (sometimes) ships with Apache. It's called ModDAV, and it seems to be quite easy to setup.
Then, in theory anyway, you instantly have the ability to PUT files there, LOCK them, etc.
Read more at The mod_dav page
-marick
P.S. Want more functionality?
Check out Sharemation for a free (5Meg) WebDAV account that has DeltaV, ACL, DASL support. (And yes, I work for Xythos Software, we host sharemation and sell the Web File Server it's based on.)
Or go check out Tigris' Subversion a highly capable free DeltaV enabled DAV server.
The afformentioned distribution is also unaffected by the following other bugs:
Nimda: IIS 5.0 is not installed by default in OpenBSD
Ping of Death: The Microsoft TCP/IP stack is not loaded by default in OpenBSD
Recent Linux Kernel Bug: OpenBSD unfortunately uses the BSD kernel and the Linux kernel is not installed by default in OpenBSD
As you can see, OpenBSD is obviously the superior operating system, for namely, its lack of features.
Thank you.
Isn't this the kind of thing people get upset at Microsoft for? Yes, I'm sure Micrsoft keeps it secret longer, and I'm sure people will tell me that Microsoft wouldn't fix their code at all if they didn't have to, but it seems to me that I've more than once seen on Slashdot posts complaining how Microsoft wants to "shush" bugs/security holes until they have time to fix them. And now we discover that Linux distro vendors do the same thing? Seems to me a few zealots should do some thinking about this...
While doing the RHCE a few months back, the subject of wu-ftpd came up and all the existing sysadmins kept asking "Why ship this piece of crud?".
The tech (and unfortunatly I forget his name) claimed that a code audit had been done on wu-ftpd by RH engineers, and it should be safe now.
RH should just stop throwing good money after bad.
---
Silence is consent.
Thank you Redhat.
Not a single mention on the wu-ftpd.org web site. What about us folks who have this compiled on a real genuine (read: proprietary) UNIX(tm) box and not some Linux distro?
Anyone know where there are source patches or a new source rev of wu-ftpd around?
Latest on their ftp server...
-r--r--r-- 1 wuftpd wuftpd 341520 Jul 1 2000 wu-ftpd-2.6.1.tar.gz
Bugtraq used to post vulnerabilities as soon as they received them, with or without exploit source code. They were truly a full-disclosure mailing list.
Note that it has long been considered "courteous" to email the vendor at least two weeks prior to sending your exploit out to the whole Bugtraq list. But in general, the moderators left this to the submitter and did not censor submissions which ignored this courtesy.
Nowadays, especially since the move to SecurityFocus, Bugtraq is caving to the demands of the vendors. The list isn't full disclosure - at least not by the definition is used to be.
Full disclosure = being widely published. After all, what's the point of only disclosing a hole to a certain number of people, when the people who DON'T get the announcement are the ones that need it?
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.
I will personally e-mail Red Hat and the person/people involved with security publications to urge them to NOT punish the guy for his "mistake" and push for earlier releases for them.
If you want a step-by-step guide on how this process works, here it is (in order):
- Cracker/hacker discovers a security hole.
- S/he tells his close circle of cracker friends.
- Somebody outside the cracker community finds out about the hole (usually because they were cracked) and tells the author of the software.
- S/he tells a close circle of developer friends.
- They tell the vendors, but say to "keep it a secret".
- They work on fixing the problem for a few days/weeks.
- The vendors FINALLY release a statement and the public gets notified.
All throughout steps 1-7, there are r00ted servers all over the place. This is usually over a long period of time, and nobody knows why because it's never public knowledge. If this was already known by step 3 (or at least step 5), then the sys admins can rush to turn off the daemons or lock down the boxes before they get r00ted.Waiting for a patch for a security hole before telling the public is like waiting for a cure for AIDS before telling the public.
Zodiac Survey
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.
WU = Washington University, in St. Louis, Missouri.
/. is irrelevant.
CERT's been a poor (and untimely) source for security information for a long time. Most good sysadmins sign up on several security MLs, including CERT, but CERT is usually the last one to find out (or tell you).
Zodiac Survey
I made a mistake. wu_ftpd is not 8000 lines, it is 24,000 lines.
fer christs sake. kill this fucking dameon by now. its over. too many bugs. die.die.die.
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
OK, CERT to wait until all the distros want to release their updated fixes for the bug? What about us and our "custom" distros? How much better is this than Microsoft waiting weeks before issuing a patch for a known flaw?
3. Somebody outside the cracker community finds out about the hole (usually because they were cracked) and tells the author of the software.
At which point an advisory is made, and the whole world knows.
4. S/he tells a close circle of developer friends.
At which point somebody posts to bugtraq, advisories are made, and the whole world knows.
Imagine an alternate scenario, in which the cracker/hacker from your first step is somebody from CERT, the development team of the server in question, or one of the engineers working on one of the Linux distributions. And imagine that the close circle of friends in step 2 is CERT and the vendor private list. This eliminates steps 3-5, and servers are not being rooted while ignorant sysadmins get shafted by the distribution vendors. In situations like this, it is perfectly safe and quite reasonable to delay the public announcement while the distribution vendors can prepare for it.
In the case where somebody from outside the CERT/distribution vendor circle discovers the vulnerability, the distribution vendors are going to hear about it at the same time as everybody else, and you've got your immediate full public disclosure. But in the case where the people who discover the vulnerability are the same ones who can fix it, then delaying the announcement while a fix is prepared is both responsible and ethical.
noah
"Red Hat didn't do anyone any favors with this."
apt-get remove wu-ftpd
apt-get install pro-ftpd
Thank you Redhat. Or should I say thank you Debian?
My Karma was at 49, then they switched to words. All that work for nothing!
What's another form of security? Security based on sound techniques where one can disclose the nature of thier mechanism and it still be secure.
Example:
1) Company A encrypts a key file in thier software using DES because "that's good enough", and they rely on the fact that no one knows that they use DES as a means of security. "They can't even brute force it, they don't know what encryption mechanism we are using. DES is good enough!"
An attacker then does a few simple tests, say disassembles the binary that is used as a tool to encrypt the file, and figures out that they are using DES and runs a few tests where they produce a encrypted file where they know the plain text, and proceed to brute force for the key. This was a mistaken notion of security through obscurity.
2) Company B encrypts a file for thier software, but they use RC6, and then encrypt that file with Two-fish. Or heck, use a totally different security mechanism where this file doesn't even need to be encrypted because it's inherently secure. Then they disclose how they do it so that the mechanism has peer review to make sure that security can be improved in the future.
Aside from these obvious points, your other arguments are totally bogus from a security standpoint. A company or organization can easily prevent simple "social engineering attacks", using security procedures in thier company. If they are good procedures, they could even disclose them to the public. Your argument that "Well, if someone wants to, they can get into your system anyway." is absolutely not security concious. I don't see why any of this has to do with Intellectual Property either, it's just logical.
I gaurantee you Securityfocus found out about this it was because some hacker group on IRC has been using it for weeks. Trading it amongst themselves for whatever, and someone leaked it to them. For them to "hide it until the vendors can make a fix" just extended the time that these current criminals could use it, and left my system at risk. I agree with RedHat. I'm sure the fix is a one or two liner, and I wanted it as soon as they found out about it. Not when they were ready to tell me.
> Do tell me the other forms of security.
Encryption
> Passwords and encryption _is_ the same as obscurity.
Nop...
My point is I think you're misunderstanding what it's call obscurity: no matter how deep you buried your shit it'll stink anyway OTOH better expose a nice smell without a shame ;)
Personally, I'm not a believer in hoarding the exploits until some of the lazier vendors decide to release a patch. Something this serious needs to be addressed immediately. Anything less is a disservice to the people who place their trust in their OS vendor. 99% of the folks out there can't be bothered to hover on every new posting on Bugtraq (just us admins with no life) so they rely on their vendor to alert them to problems promptly.
OS Darwinism will dictate that those that are slow to release patches will generate more irate customers and fewer repeat/new customers.
Cheers,
Ritz
Security through obscurity is bad!" What other forms _are_ there? Passwords and encryption _is_ the same as obscurity
-
The thing that is obscure should be different at every site. Passwords and encryption keys pass this test. Flawed daemons and cipher weaknesses do not.
-
De-obscuring a well-chosen password requires trying every possible string of the maximum password length or less. It is easy to figure out how much "effort" (ie CPU time) this will require, which means you can easily determine if you have made cracking your security hard enough that doing so costs more than the information/resources you are protecting are worth to an attacker.
- Adam (adam at megacz dot com)De-obscuring a flaw in an unpublished security mechanism can be done a number of ways, many of them not known to the administrators or security auditors. Hence you cannot put a "lower bound" on the amount of effort required to crack your security. Hence you have absolutely no guarantees.
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.
Good thing Redhat released fast, sploits for this have been running since last saturday.
/sbin/init
/sbin/init
Two scripts I've seen, once overwrites
the other just loads a lkm
Check stealthed processes and your
Nmap won't show the open port, sploit is controlled by ICMP Arp request payload.
http://www.chkrootkit.org/ will detect it.
mycal
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.
Kiddies almost ALWAYS know first, and even though it may not be public, there will be thousands of them running around with private exploits while the vendors are trying to keep people safe by not saying anything. I'd rather know as soon as possible so I could react with the optimal amount of time
Robort knows all.
Yeah!
:)
0K!
This is why I don't have to spend all night patching our company's servers anymore
Learn on Linux.
Live off OpenBSD.
JSM
... I thought you were not suppose to run wu-ftpd because it was well known for the security holes and buffer overflows.
Did I miss something?
ChozSun
ChozSun.com
Who said "security thru obscurity is bad"? I've always carried a lot cash with me, and who'd have guessed which pocket I put it in each time? It's just as safe as using an ATM card and a 4 digit PIN,-what's the difference with guessing a PIN and picking a pocket anyways?-and a lot easier to implement!
:)
Credit cards? Pfff, those paranoid wusses...
Programmers make mistakes. That is why it is called programming instead of typing.
Well, no. It's called programming because ppl program. Programming is a superset of the typing activity.
Per "Brad" on Bugtraq:
OpenBSD's ftpd exhibits the same behavior, 2.9-stable, 3.0-stable and -current.
// Brad
OpenBSD uses ssh.
sftp clients? For Windows check out Putty. So you want a *nix client then of course Openssh is available. I agree with your statement that anything plugged into a network is not bulletproof but some systems have proven themselves to be much stronger than others.
Enough Said.
Courier is nice mailserver it has three major problems which may or may not live with:
On the plus side the mailing list is very good despite Sam Varshavchik unhelpful posts.
Security is on the high side by default and is easy to configure when you find what each config file does!
I can live with broken email clients/servers not being able to send me mail.
To protect against unknown exploits, there are kernel patches like LIDS . 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.
/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.
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
{{.sig}}
First a disclaimer:
I don't like ftp in general and wu-ftpd in particular. Let's get that out of the way.
But ftp is an important service and wu-ftpd is attractive because it's default on many distros.
Saying something like "What, you still run (wu-)ftpd? Are you stupid?" is IMO a stupid statement. If you have time to burn and the server serves only you, then yeah, it is dumb to run an external ftp service.
But if you have to slap together a test bed in 15 minutes for a bunch of web designers who will be working from remote, then no, it's a serious issue.
The fact is dreamweaver does only ftp. Many designers have come to depend on this service, and you can't teach them to scp individual files over to a test bed behind a firewall. Researching and testing out various ftp servers (proftpd, et al) takes incredible amount of time. Time I simply do not have.
Ideally, I would like to run a bug-free ftp server behind my firewall and configure my iptables to competently weed out unwanted ftp visitors.
To that end, I need:
1. A bug free ftp server
2. iptables/ipchains script to allow the ftp ports to open up as needed.
The latter is tougher than I thought, because something breaks during ftp transaction in the firewall, and dreamweaver fails to open a connection.
Any takers?
Somebody please tell my why the 'blackhats' shouldn't have figured out the bug from this info below
This was posted to BugTraq on the 20th November:
From vulnhelp@securityfocus.com Tue Nov 20 15:18:29 2001
...
From: Vulnerability Help
Date: Mon, 19 Nov 2001 12:49:47 -0700 (MST)
To:
Subject: Vendors For WU-FTPD Please Read
Heya all,
The SecurityFocus Vulnerability Help Team is in the process of notifying
vendors of a remotely exploitable problem in WU-FTPD . Rather than miss
any vendors we are asking vendors which read Bugtraq and ship WU-FTPD
either as a default package or a ports package to please mail us your
relevant security contact information (with a PGP key please). The WU-FTPD
has been notified already.
Cheers,
SecurityFocus
Vulnerability Help Team
So, only the 'good guys' are supposed to know what the bug is, huh ? And the rest of us has just to sit there as ducks on water ?
It has been shown before that's enough to state that *there is a bug*, and somebody will find it. And it only takes one 14 year old
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
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...
How can people trust software with holes? You mean like the Linux kernel? (corrupted filesystem in 2.4.15) or the MAC iPod installer (erases disk drive), or just about every other piece of software out there? ;-)
Of course everyone brags that OS XYZ has "fewer" bugs. That's like saying a mass murderer killed "fewer" people.
Face facts. All software has bugs. I gotta laugh at this one though. Although it's not Linux specific there are a lot of sites running wu-ftpd. Someone could write something just as bad as Nimda. Reassuring to know that my Microsoft software isn't the only piece in the world with big holes in it.
And anyway, everyone knows real men run AIX.
Perl exploits? Eh?
You mean badly written Perl scripts? Or the mod_perl equivalent written by a third party for IIS? Or perhaps you meant something else?
Score:-1, Funny
I know that SuSE for one have released their patch already (available from ftp.suse.com). Those who make accusations of hypocrisy should remember that the purpose of these release dates is to give reasonable time for vendors/distributors to fix bugs before releasing the information, Microsoft/ closed source vendors are given the same time as Linux distributors to fix bugs, it's just that they frequently don't make that time, whereas Red Hat jumped the gun.
If you haven't learned yet, don't use wu-ftpd (or sendmail, or BIND, or any number of other common widespread programs that are so scrutinized that they develop root exploits every other week).
About a year or so ago proftpd was being hit with root exploits left and right. They'd put out a new version and it would be vulnerable, they'd put out another new version to patch that and it would be vulnerable to something else. I think they've pretty much gotten it to a semi-decent point but their claim of being a "secure" FTP server built from the ground up with security in mind went out the window after all that. It's sad too since it really is a nice FTP daemon for doing virtual servers. When it comes down to it, the only secure FTP daemon is not using FTP at all I guess (or you could go insane and use DJB's publicfile stuff :-).
But just because you have your source code sitting around in public doesn't mean someone's going to do a free security review on it, either, which is what the open-source guys think.
Er, OpenBSD, anyone?
Theo seems to be a fairly abrasive little fucker, but god bless his black little heart for doing this sort of work for the benefit of all.
--saint
That is an eyeopening link, and really dissapointing. The linux community needs to remember stuff like this and not be repeatedly blinded by the hype from bafoons like the postfix author.
According to this BugTraq post, bsd-ftpd might be vulnerable too!
Re: *ALERT* BID 3581: Wu-Ftpd File Globbing Heap Corruption Vulnerability
Date: Wed, 28 Nov 2001 18:36:19 -0500 (EST)
From: "script0r" script0r@axenet.org
To: bugtraq@securityfocus.com
[...]
I am running the a linux port of the bsd ftpd and it might be vulnerable to
a similar attack,
ftp localhost
Connected to localhost.
220 playlandFTP server (Version 6.5/OpenBSD, linux port 0.3.3) ready.
Name (localhost:user): ftp
331 Guest login ok, type your name as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls ~{
200 PORT command successful.
421 Service not available, remote server has closed connection
in inetd I find an error stating that the ftpd process has died unexpectedly
Nov 28 14:21:28 playland inetd[82]: pid 16341: exit signal 11
Order is for idiots, geniuses can handle chaos!
bsd-ftpd is listed as affected, but that's not the OBSD ftpd, it's the port of it to Debian, I believe. I could be wrong, but there is not bsd-ftpd w/openbsd, and when I search google the only results are the ported versions of open's ftpd. Thanks for helping me understand that further :)
I completely agree with withholding the details of how to conduct an exploit, but publically list affected version numbers as well as consequences of a security bug. In this case this is what RedHat did. The Security Focus posting by them does not contain any details of how to reproduce the security vulnerability, so the most they're doing is tipping off black hats that there is some buffer overflow. It will as long for the smart black hats to release the scripts for kiddies to play with as it will take the white hats to fix it.
Basically until everyone has had time to patch a security bug, just release enough information for people to conduct a risk analysis.
If RedHat had said instead, "Issue the following statement to Wu: xxxxxxxx, and you'll now have root shell access" then I'd say we should tar and feather them. That's far more information than is needed to conduct a risk analysis.
Slay a dragon... over lunch!
I wrote/spoke too soon I believe, here's the post:
Brad's link at Buqtraq
C(r)ISCO?
I'll dump this Linux stuff and load Windows XP.
With XP, full disclosure of problems happens quickly, whether MS wants it or not.
Linux coders pretend that its secure by hiding the problems.
this is not a sig
I was just listing software packages adored by many slashdot style hackers that have had buffer overflows. I was thinking particularly of suidperl, which has had many holes, at least one of which was a buffer overflow:
m es s.html
http://www.insecure.org/sploits/sperl.overflow.
Perl scripts are often dangerous (as most people know), but for a different reason that I didn't address in my post.
I mean, did they do background checks, dna samples, etc before allowing access to the Mailing List? I think not. And how do they control access to the list anyway? I mean, I refuse to beleive that they have dna-activated smart chips embedded in their skulls. The point is, someone, somewhere, can read the mailing list in an unauthorized way. Your average script kiddie isn't likely to have access to it, but an secret shared is no longer a secret. And where do they get off, "scheduling" the release of an exploit.. HELLO! the exploit has been there all along. Disclosure dates are just a way for these companies to protect theri corporate images. They have evolved into businesses that have to do that sort of thing.
My opinion is, tell the world as soon as you find out, because that way the various software maintainers will be under the pressure to fix the problem fast. If they don't fix it fast, their users will start to find alternatives. How many weeks has this one been in the works? How many thousands of boxen could have been compromised in the interim? Who made these people God anyway? After all, the options are simple, even without a fix: you turn off FTP, or find some other deamon.
If you wanted your box to be secure, why did you ever plug it into the Internet anyway?
grepping for ":on" won't do it for 7.0 and later! chkconfig reports the xinetd-based services at the end with just a plain "on". This includes all the really critical services, including wu-ftpd itself.
Wu-FTPD. Proudly handing out remote root exploits since 1996.
This is what you get
for running a daemon
written by the Wu-Tang Clan
--
I noticed
It's getting about time to leave everywhere
Suggested alternatives:
http and other non-upload services - nope, no good.
webdav - nope, clients not readily available, needs web server
proftp - sorry, they've had too many serious holes in the last year to be considered, maybe in a few years time
pureftp - maybe, but it's only 3 months since it reached release quality, how can we trust it
So you see, wu-ftp, holes and all has needed features and gets patched pretty quickly.
Please, where are the alternatives.
> conventional wisdom says that if you want ultimate speed, use C
Not to nitpick, but the conventional wisdom says to program in the lowest language possible -- which is usually assembly. Assuming, of course, speed is your goal, not reliability (the two aren't necessarily mutually exclusive).
Of course, if you can go even lower, then all the better: microcode, vhdl, specialized computer architecture, asics. But these options aren't available for 99.9% of pc programmers, but are routinely used by embedded programmers.
HIV Crosses Species Barrier... into Muppets
Well, I just spent two hours trying to get all of the dependences straight so that I could upgrade to the RedHat provided RPM. All of my newer boxes are Debian, and I had forgotten how nice "apt-get install" is. I had to upgrade, PAM, glibc, libxml, popt, etc.. It's a dependency hell. After getting everything fixed except for the below error message on upgrade:
/pub/up2date/rhl-* directories. Finally, I got wu-ftpd upgraded. RedHat could at least try to make it easier. Computers are made to automate things.
rpmlib(PayloadFilesHavePrefix)
I took a stab in the dark that I needed to upgrade RPM. Of course, that involved another round of downloading more RPM's to meet the dependencies. Also, the RPM RedHat in the usual place isn't new enough. You have to go to the
PS: Posted as an AC, because the machines my web site and e-mail aren't upgraded yet.
No waiting, no futzing around, no bitching, no pissing, no moaning.
Just tell us about the bugs so we can either patch the software, temporarily disable it, or replace it with a secure alternative.
The security of my computer is my responsibility, and i don't blame anybody else for it.
Thats one of the reasons i run an open source OS, with open source applications.
I don't want Red Hat, Microsoft or CERT to pat me on the head and tell me it will all be better in the morning. I want to know ther is a vulnerability so that i, personally, can take action against it.
I gots ta ding a ding dang my dang a long ling long
Bind seems more like a she than he:
hard to understand
troublesome
swift and elegant in action
but prone to breakdown
Finally, a patch is available from the wu-ftpd.org website.
The Virtual Bookcase: book reviews
It's in all major distros of Linux. None of the BSDs are impacted.
According to an an article on incidents.org, this vulnerability was originally noticed back in April, but at the time was not believed to be exploitable. Scary thought huh? You can view the article here.
I think servers should be written in a proven safe version of Unlambda. The language is small enough that a rigorously safe implementation may be provable from scratch. Furthermore, since Unlambda has first-class functions, it is much superior to languages such as C. Also, since the language proper contains only three characters, typing it is very fast. You can map the alphabet plus semicolon to all 3^3 combinations of three characters, TRIPLING your productivity!