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.
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?
You don't see Microsoft doing this, do you?
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.
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!
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
I'm somewhat surprised--but either way it brings the unresolved question of disclosure bubbling to the froth again.
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
Plus, its pretty bad since whenever micorosoft gets something like this, people get pissed off if they take more then a weekend on it. Here, they took almost a week longer then RedHat, makes you wonder how long this sploit was in hacker circles, and how long the distros knew about it. Whatever happened to the claims of fast reaction in the opensource industry vs. old-skool business?
This isn't a troll, but an honest question - what tookem so long, and why didn't they just throw it open to end-users to protect themselves (like closing down ftps in worst-case) like is supposed to be standard practice?
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?!
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
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
It wouldn't be very cool of them to leave me vulnerable to a break-in when the fix is available. And the fix is available in the wu-ftpd package, regardless of whether the various distributors have packaged it for their systems, so I can install the fix even if my vendor hasn't gotten it's act together.
My whole complaint with the non-full-disclosure movement is that vendors under it tend to not acknowledge that security holes exist (which means I can't even do something as simple as disable the vulnerable service until a fix is out) and delay putting patches out (so I'm either vulnerable or off the air longer than needed). I'd be more annoyed at CERT for not reporting the vulnerability than at RedHat for telling me about it.
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
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
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.
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.
I real basic terms, to glob is to expand a wildcard character to mean one or more characters. Like if you say something like "sudo rm -rf /*" that asterisk is expanded to mean "zero or more of any character". You might have also seen the question mark used. It means one single character. The Foldoc web site has a much better explanation.
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.
Vegemite is a nasty product made of yeast extract. It's a brownish paste-like stuff which is spread on bread and the like. An Aussie could probably explain better. I tasted it just once (on a cracker), and that was enough for me.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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.
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 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
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.
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!"
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.
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
No, I actually only had a wee little bit on a cracker. It was foul. Seems to me to be an acquired taste, like caviar or something.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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.
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
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
Gary McGraw must be a troll as well. He even mentioned this in a book he wrote.
What's open source's role in the security-by-obscurity debate?
Open-source software is neither more nor less secure than closed-source software. And the whole issue of whether open source is more secure is a red herring. We have a chapter in the book about it. Security by obscurity doesn't work. 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. That's wrong.
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
I was too lazy to look up specific stories, but here are a few that are critical of Microsofts stance on withholding information.
I'm fully aware that the Slashdot Readership holds a wide spectrum of opinions. However, Slashdot is definitely a soapbox for the editors, and they should make their minds up about which issues they support and not take a different stance because the issue affects an open source org rather than Microsoft.
PS, as long as we're making overly generalized assumptions, the Slashdot Readership also treats Microsoft as a monolithic entity.
No, Thursday's out. How about never - is never good for you?
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?
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.
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.
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.
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.
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
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.
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.
IIRC, you can tell rsync to connect over ssh to do this kind of job.
Why is proftpd supposedly more secure, though? They are both written in C, and secured by the many-eyeballs (if even) method. As I recall, proftpd has had plenty of remote exploits itself.....
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?
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.
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.
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.
Yea dselect blows. I bit the bullet and learned the apt-* command lines.
For me it was always hitting the wrong key. Who chose that key scheme anyways.
War is necrophilia.
Certainly, however what about next time? As a Red Hat customer would you want to bit hit by an exploit that another vendor had discovered and patched, in the time it took for Red Hat to catch up. Is the loss of such cooperation and posibily kicking of the escalation of a patch war really such a good idea? Are you certain that Red Hat will be first every time? Want to watch this escalate and cause problems elsewhere?
troodon.net
the alarming thing this time is the Linux guys adopting the Microsoft methodology for patching leaks. sit on their ass while boxes get rooted and release the patch when the "agree" to do it. don't tell anyone who might just code a patch into the source themselves. can't have that, can we?
cat
Like they did with BIND 8.2.3? I had all my systems patched within hours of reading about it. Now _THAT_ was some good service.
cat
I don't think his point was whether or not this story even mentioned Microsoft or not. I think it was more along the lines of, replace "Linux companies" with "Microsoft" in this story, and the editors would have a whole different tone.
But does that even surprise, let alone phase, any regular reader of this site anymore?
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
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}}
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...
If the distro's all stuck to the Linux File system standard, what difference would it make? My SuSE would install the Redhat rpm just as easily as a Redhat distro! sure maybe we'd have to be a little more carefull about which version of the distro we got the update from when doing cross-distro stuff because of library version differeneses but that should be about all.
If every one wasn't reinventing the wheel, who'd care whose wheel turned faster. Ok I know it isn't quite that easy, My MySQL server doesn't autostart because SuSE names a script a little different, but its pretty close.
I get the impression that WuFTP isn't the default ftpd on most of the distro's that were caught flatfooted. SuSE ftp site has been over loaded all week at 5 am EST so a lot of people have been downloading something; I'll bet more people have got the patch before it was announced to the general public than we realise.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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
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!
Well, there is SSH, and if you want, you could have them use MindTerm, which has an attempt at a sFTP to local FTP proxy built in. Never got it to work, but it could be just the ticket to letting Windows users use their favorite FTP client to access sFTP.... :) Even if it were secure, the whole mechanism sucks, can't easily be port-forwarded, and uses two ports. Those ports just makes it that much easier for a sniffer to differentiate between transefered data, and command data (i.e. passwords in plaintext).
http://www.mindbright.se/mindterm/ is mindterms url, check it out.
On the other hand, putty has both pscp, and a psftp in development, that also provides this functionality.
Ftp is a really ugly and insecure protocol, it needs to die
XML is like violence. If it doesn't solve the problem, use more.
"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)."
So, what you're advocating, then, is security by obscurity, in effect. I don't think that Sendmail, bind, etc. have security holes merely beacause they are more closely scrutinized--it's really more becuase they were written way back when in a more "gentle time" when authors didn't have to worry so much about stack smashing, buffer overflows, and all the other tricks so common today. These applications come from a older codebase--it's hard to retrofit secure programming practices onto older code. It's much easier to design with security in mind from the beginning. Consider the example of qmail as compared to sendmail. Where sendmail is basically one large, privleged binary that handles all aspects of mail delivery, qmail is actually a group of smaller, lesser-privleged binaries that handle one specific component of the mail delivery process. Same goal, different philosophies, less root holes (I think none to date for qmail). As many other posters have pointed out, there are similar alternatives to wu-ftpd that were designed with security in mind from the beginning, and therefore simply don't have root holes to be discovered--no matter how closely they're scrutinized.
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.
I disagree. Maybe one of these days I'll actually get off my behind and write a C translator that actually does detect and reasonably handle common memory allocation and pointer-related errors.
The point is that there's nothing in the C language specification that makes it inherently less safe than any other language. Just because almost all C implementations don't do bounds checking on array and pointer access doesn't mean that it's impossible to do so, for instance.
For example, consider a compiler that converts C code into Java bytecodes. Obviously (?), programs compiled with that compiler would have all the same protections against memory corruption and unintended access that a Java program has...
-Mark
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