Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Bug

Wu-ftpd Remote Root Hole 515

Posted by michael from the taking-anonymous-access-a-little-too-literally dept.
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.
This discussion has been archived. No new comments can be posted.

Wu-ftpd Remote Root Hole More

Wu-ftpd Remote Root Hole

Comments Filter:

  • Wu-FTP not in OpenBSD (Score:3, Interesting)

    by Geekboy(Wizard) ( 87906 ) <(spambox) (at) (theapt.org)> on Wednesday November 28, 2001 @08:57PM (#2627992) Homepage Journal
    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!
    • Wu-FTP is not included in all major Linux distributions.
      The latest Slackware comes with ProFTPd.
    • 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
    • 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?
      • Look at the BUGTRAQ advisiry. ;-) http://aris.securityfocus.com/alerts/wuftpd/ [securityfocus.com] is quite useful. It looks like it's a run-of-the-mill buffer overflow. There are currently no IDS sigs that can detect it (but I'm sure that will change as soon as I post this.) If you can, disable anonftp access. If not, look through the log files for an extreamly long command. (The description shows 60+ 'a' in a row.)


        This is very similar to an exploit discovered about 4 months ago. Why didn't the Wu-FTP people check to see if they were vulnerable?
    • 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.

  • I've changed my mind (Score:5, Interesting)

    by child_of_mercy ( 168861 ) <johnboy AT the-riotact DOT com> on Wednesday November 28, 2001 @08:58PM (#2627996) Homepage
    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 WAS a "please contact us at wuftpd so we can co-ordinate", sent out on the 17th, if i got the date right.
      • http://www.securityfocus.com/archive/1/241105 is the link, just looked it up. Was on the 19th, close enough.

        And what's with the broken counter on replies on slashdot? It claims it was 14 seconds ago that i replied.. I'm sure i didn't find and type the above paragraph, in a mere 14 seconds.
    • I haven't.

      It's not like only Redhat distro users can now get a safe version of wu_ftpd--it's just that not everyone (neccessarily) has the packages ready for all there configurations.

      If you have 6 boxes, better start checking versions and installing newer ones. Sure it sucks, but it's better than being surprised when your servers are "owned"

    • Re:I've changed my mind (Score:4, Flamebait)

      by andrewski ( 113600 ) on Wednesday November 28, 2001 @09:15PM (#2628119) Homepage
      The script kiddies probably knew about this long before CERT did. This is the major problem with private bug lists for vendors; It gives script kiddies a while to continue exploiting boxes while the vendors prepare patches. I would rather know right away, disable FTP, and do without for a few days, than wait until the bug was fixed before I am informed. Private lists, like all other forms of security by obscurity, are inherently ineffective.

      • Re:I've changed my mind (Score:4, Insightful)

        by reflective recursion ( 462464 ) on Wednesday November 28, 2001 @11:06PM (#2628637)
        Do tell me the other forms of security.

        I hear this all the time. "Security through obscurity is bad!" What other forms _are_ there? Passwords and encryption _is_ the same as obscurity. People using this "security through obscurity is bad" argument seem to have another agenda: tearing down IP laws and promoting freedom of information. While IP may be bad, it is a very seperate issue.

        How do people claim security through obscurity is a bad thing? Why is it bad? How else does security work? There is physical security or there is abstract/obscure (i.e. encryption) security. What else?

        There is also insecurity through ignorance, which seems like a disease in the networked world. It really doesn't matter much if you post the memo on the admin/end-user's forehead if they don't bother to read it. This seems to be the case more than script kiddies finding out before knowledgable admins. After all, where do script kiddies get their info? Same place admins do: Bugtraq. By the time those damn elusive script kiddies on IRC exploit a few holes in nasa.gov, I'm sure at least one knowledgable admin has posted a report to bugtraq. In case you didn't pick up the sarcasm, most script kiddies travel in herds and attack usually obvious "high-risk" sites. If someone knows something before Bugtraq, I'm sure you have very little to worry about. The exploiter is probably a knowledgable cracker and probably has specific targets. If you happen to be a target, I wish you well, but I don't think any amount of Bugtraq info will keep someone determined to get in your system out (hint: There is a whole world of social explotation that is damn near impossible to detect or even be aware of).

        • Re:I've changed my mind (Score:5, Insightful)

          by Garc ( 133564 ) <jcg5@po.[ ]u.edu ['cwr' in gap]> on Thursday November 29, 2001 @12:16AM (#2628997)

          Hmm, when I think of "Security through Obscurity", I tend to think of it in a different way than thought of above. I think of it as keeping the method used to encrypt/secure/hide something secret, thinking that because the method is secret it is secure.

          For example, say I develop a new top secret encryption scheme, called Rot-13. I tell no one of how it works. Since I am not a professional cryptographer, the chances are my algorithm is not cryptographically sound. So it is only secure as long as its method is secret. Once the secret is out, its security is gone. This is security through obscurity.

          An example of the opposite would be RSA. The algorithm is well known, therefore with peer review, it is thought of as secure. Even though I know how RSA works, I'm still unlikely to be able to crack it if used properly.

          regards,
          garc

    • That's why I recommend not using WU-FTP. It's full of holes! Like swiss cheese. About as bad as Sendmail. Use something more secure.
    • If you're concerned about security you're not using wu-ftpd anyway. They have a remote exploit found about once a month.

    • Re:I've changed my mind (Score:5, Insightful)

      by orkysoft ( 93727 ) <orkysoft@m y r e a l b ox.com> on Wednesday November 28, 2001 @09:31PM (#2628181) Journal
      The fact is, the blackhats have known about this vulnerability for some time, so fix or no fix, you need to be aware of it, so you can disable your ftpd if you think the risk is too high.

      Not disclosing this asap will only give you a false sense of security, and will deny you from making your own risk assessment.

      Hell, why do you think Microsoft wants to limit disclosure? To empower the sysops? ;-)

    • Re:I've changed my mind (Score:5, Insightful)

      by kimihia ( 84738 ) on Wednesday November 28, 2001 @09:35PM (#2628198) Homepage

      Well then close the service off. An unuseable service is better than a r00ted server.

      It is good to know that it could potentially be rooted. Being ignorant of security holes does not make it secure - no matter what Scott Culp may tell you.

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


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

    • As a RHN subscriber, I received the notification on Nov 27 with instructions on receiving a patch. Subscriptions are free for one machine per email address (*ahem*), without any other requirement (you don't have to buy a distro from them to sign up; yes, I bought a box of 7.2).

      Here's the alert (minus my system info and edited to avoid the LAME lameness filter):

      ---
      Red Hat Network has determined that the following advisory is applicable to
      one or more of the systems you have registered with the Software Manager
      service:

      Security Advisory - RHSA-2001:157-06

      Summary:
      Updated wu-ftpd packages are available

      Description:
      An overflowable buffer exists in earlier versions of wu-ftpd.
      An attacker could gain access to the machine by sending malicious
      commands.

      It is recommended that all users of wu-ftpd upgrade to the lastest
      version.

      --
      Taking Action
      --
      You may address the issues outlined in this advisory in two ways:

      - log in to Red Hat Network at https://rhn.redhat.com and from the
      listing showing under 'Your RHN' select the affected servers and
      download or schedule a package update for that system.

      - run the Update Agent on the affected machine.

      --
      Changing Notification Preferences
      --
      To enable/disable your Errata Alert preferences globally please log in to RHN
      and navigate from "Your RHN" / "Your Account" to the "Preferences" tab.

      You can also enable/disable notification on a per system basis by selecting an
      individual system from the "Systems List". From the individual system view
      click the "Details" tab.

      --
      Affected Systems List
      --
      This Errata Advisory may apply to the systems listed below. If you know that
      this errata does not apply to a system listed, it might be possible that the
      package profile for that server is out of date. In that case you should run
      'up2date -p' as root on the system in question to refresh your software profile.

      There is 1 affected system registered in 'Your RHN' (only systems for
      which you have explicitly enabled Errata Alerts are shown).

      Release Arch Profile Name
      7.1 i686 localhost

      The Red Hat Network Team

      This message is being sent by Red Hat Network Alert to:
      RHN user login: localhost
      Email address on file:

  • linuxtoday.com (Score:2, Interesting)

    by jonsmirl ( 114798 )
    Is this how Linuxtoday was just hacked?

  • My favorite quote (Score:3, Interesting)

    by Reality Master 101 ( 179095 ) <<moc.liamg> <ta> <101retsaMytilaeR>> on Wednesday November 28, 2001 @08:58PM (#2628003) Homepage Journal

    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!

    • That's not so unreasonable. The vast majority of boxes have little reason to run an ftp server -- it should be disabled on most machines anyway. (scp/sftp is a good alternative in many cases, and of course there's always http, which, although there's obviously lots of potential for problems there, at least isn't such a pain with firewalls).
    • Your whole system is only wide open if you can access the FTP service.

      That's not a problem to me, as I would never expose an FTP port to the outside world. The FTP protocol is inherently difficult to secure and it has outlasted its usefulness. For outgoing data, you can just use HTTP. And public access for incoming data just means that you will be hosting gigs of ripped movies and porn. FTP should be filtered at the firewall and made available to trusted hosts only.

      • For outgoing data, you can just use HTTP.

        I don't think routing all data transfer through HTTP is a panacea... perhaps it offers better "out of the box" security than your average FTP service, but your comment smacks of the tendency to run with port 80 [slashdot.org] hashed and rehashed earlier on Slashdot.

        You're comments are spot-on as far as trust and public access are concerned, I simply question the view that HTTP is a simple (and better) replacement for FTP. Obviously, FTP implementations have their issues (and *big* ones, too) with security, but to me, HTTP can't really offer all that FTP does in terms of file transport.

        Please correct me if I'm wrong.

        Minor unrelated peeve: why is it that Slashdot's search indexing exclude words of fewer than four characters in length? Silly ... I couldn't search for XML as a keyword, and had to hope that SOAP made due appearance in the article I reference.

        • HTTP vs. FTP (Score:5, Insightful)

          by rcw-home ( 122017 ) on Wednesday November 28, 2001 @10:02PM (#2628333)
          HTTP can't really offer all that FTP does in terms of file transport.

          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.

        • Re:My favorite quote (Score:5, Insightful)

          by psamuels ( 64397 ) on Wednesday November 28, 2001 @10:20PM (#2628415) Homepage
          I simply question the view that HTTP is a simple (and better) replacement for FTP.

          For uploads, FTP is still probably better, if only because nobody seems to use the HTTP PUT command.

          For downloads, though ...

          • both require a new connection for each dir listing or file transfer - except HTTP/1.1 which can reuse a connection. HTTP wins.
          • FTP requires an additional TCP connection for the control info. More setup and teardown cost. HTTP wins.
          • Many sites are already running an HTTP server, so using that for file transfer means one less daemon. Mitigated by running ftpd out of inetd, which most people do, but still ... HTTP wins.
          • HTTP can use auth methods other than plaintext, and can easily have different sets of auth'd users in different directories (without using Unix permissions, which can occasionally get clunky, or you can use Unix permissions if you prefer). FTP only has user/password/account auth, and nobody uses the "account" part anyway. HTTP wins.

          What are the advantages to FTP for downloads (especially anonymous, but also authenticated)? I honestly can't think of any ATM.

  • CERT and private lists (Score:5, Interesting)

    by SClitheroe ( 132403 ) on Wednesday November 28, 2001 @08:59PM (#2628011) Homepage
    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.
    • 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!
    • This absolutely should have been released as soon as it was found. And shame on CERT, Redhat, WU-ftpd authors etc for trying to hide it. This is inexusable because the crackers and kiddies have probably had it for several weeks now. If you find a security flaw report it immediately publically so that those that could be affected can turn off the service if that is what it takes.

      However considering the quality record of wu-ftpd if you are running it on your box you don't care about security already so it could be worse. Overall people should probably be use proftpd or maybe even zope for their ftp server.

      On a plus note there are wu-ftpd packeges in incoming for sid and those might have the fixes people need to debian boxes. If you are running wu-ftpd and refuse to use something else try those.

  • Whats ethical? (Score:3, Insightful)

    by L-Wave ( 515413 ) on Wednesday November 28, 2001 @09:00PM (#2628016)
    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. =)
    • 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?")
  • AIRC, this type of exploit has been the bane of WuFTPD's existance; one of the reasons I switched to ProFTPD [proftpd.net] 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.

    • Re:Another globbing bug? (Score:5, Interesting)

      by LS ( 57954 ) on Wednesday November 28, 2001 @09:27PM (#2628158) Homepage
      Ok, so what level of security on someone's box makes them no longer a moron? Is there a canonical list of things I must do to secure a box so that I am no longer a moron? To be honest, I run my own box for personal use, and learning anything more than basic security takes more time than it's worth. Please let me know where I can go to learn what it takes to build a secure box as defined by non-moron security experts.

      LS

      • Re:Another globbing bug? (Score:2, Informative)

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

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

      • The quickest way to secure a box is to run a firewall script. Even though its a script for building ipchains-based firewalls, I still use PMFirewall [pointman.org] on all the boxes I want to tighten.

        It wants to have two interfaces, an external one and an internal one. On boxes with only one NIC, I specify the LAN-connected interface as the external one, and loopback as the internal one.
      • I run my own box for personal use, and learning anything more than basic security takes more time than it's worth.

        Maybe to YOU, how about all the other people who will get nailed when YOUR box is hacked and used in Distributed Denial of Service attacks? How about the emabarassment of discovering your box being used as a drop point for many megs of porn for sexuality other than your own? How about all the webmasters who have to put up with probes (at least) from your box after it catches the latest worm? How about your ISP being notified that you've committed criminal activity against another computer because a cracker cracked you and used your box as a springboard?

        If you can't be bothered, take your box of the internet, PLEASE.

        Steps to a (more) secure box:
        1. issue netstat -apn (adjust for parms allowed in your netstat, but if -a doesn't work, get a new one; if -p doesn't work and you're running a recent version of Linux, you've probably *already* been cracked). Understand every single tcp or udp entry. Turn off any you don't need.

        2. set up a firewall on your machine. Deny all incoming connections by default, then permit only the protocols you need from the endpoints you need to permit them from. For example, I permit http from anywhere. I permit ssh on my home box only from the outer address of the firewalls at work - and this is a good thing because ssh at one point had a hole, so I'd cut my vulnerability way down.

          Turning off unneeded services, then firewalling (actually, packet filtering) to allow only known-good protocols is 'defense in depth' - the odds of screwing up in both places the same way are smaller than for either one singly.

        3. if you're using Linux, Bastille Linux [bastille-linux.org] is a useful script (or set of scripts) that will help you secure your machine and teach you about the process at the same time.

        4. Subscribe to a security mailing list or two (CERT and Bugtraq are good). When you see something you're using there, fix it.


        Interesting story: I was doing work on a box for a guy who only had *dial-up* access and only used it to send/receive email and browse a little. He was cracked, which I discovered when his netstat wouldn't take the -p option (his version had been replaced after he was cracked, which is common - the crackers replace common utilities with versions specifically written to *not* show their activities on your machine). Ooops - time to reformat and re-install. The fact that you are on a slow link or you are obscure doesn't help much - the script kiddies pick a block of IP addressess at random and scan them all for their vulnerability du jour - if you have it, you're toast.

    • Re:Another globbing bug? (Score:5, Informative)

      by bad-badtz-maru ( 119524 ) on Wednesday November 28, 2001 @10:03PM (#2628340) Homepage
      Learn more about security before offering advice:

      Breaking chroot jail:
      http://www.bpfh.net/simes/computing/chroot-break .h tml

      Proftpd globbing bug:
      http://www.linuxsecurity.com/advisories/other_ad vi sory-1223.html

      maru
  • Playing the waiting game with the rest of the crowd could possibly increase Redhat's eventual liability to their own customers, even if it was the right thing to do.

    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.

  • Magic Lantern... (Score:2, Offtopic)

    by cperciva ( 102828 )
    Am I the only person thinking that strategically placed "dumb coding mistakes" might be the real story behind Magic Lantern?
  • 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.

  • People still trust Wu-ftpd? (Score:4, Informative)

    by Azar ( 56604 ) on Wednesday November 28, 2001 @09:04PM (#2628055) Homepage
    I gave wu-ftpd the boot ages ago. I can't understand why people would still trust this buggy, bloated "just asking for trouble" piece of software. There are better alternatives.

    PureFTPD (based on TrollFTPD)
    ftpd-BSD (port from OpenBSD)
    Virtual FTPD (based on ftpd-BSD)

    are all good examples of decent alternatives. I've even heard good things about vsftpd.

    Some people (myself not included) even consider ProFTPD to be a viable alternative.

    How can people still trust software that has had more holes in it then the finest Swiss Cheese?!

  • Why use Wu-ftpd (Score:2, Informative)

    by niekze ( 96793 )
    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!

  • how would you exploit this, though? (Score:3, Insightful)

    by tim_maroney ( 239442 ) on Wednesday November 28, 2001 @09:08PM (#2628075) Homepage
    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

    • Here's how... (Score:3, Informative)

      by mbessey ( 304651 )
      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

  • Stop using stupid C language (Score:3, Insightful)

    by Faré ( 6486 ) on Wednesday November 28, 2001 @09:08PM (#2628076) Homepage
    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].

    • Re:Stop using stupid C language - good point (Score:4, Insightful)

      by victim ( 30647 ) on Thursday November 29, 2001 @01:53AM (#2629288)
      It is a good point. Poorly made, but there is a good point hiding in there. I see the article has atracted 6 flame replies and a -1 troll before I read it.

      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.
  • 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.

  • more to the story (Score:5, Informative)

    by Phexro ( 9814 ) on Wednesday November 28, 2001 @09:16PM (#2628120)
    item: the version of wu-ftpd that rh released was a pre-release from cvs. they changed the version number. this bug was fixed in cvs months ago.

    item: the securityfocus vuln-help people are supposed to help coordinate vendors & the software maintainers. they sent notification of the bug to the wrong address, so the wu-ftpd developers weren't even aware that there was a bug present until the day the rh advisory went out.

    item: there was supposed to be a coordinated advisory put out on dec. 3rd. rh preempted that, causing this nasty confusion.

    greg lundberg posted a big explanation of what went on to several mailing lists... it should be on the wuftpd-questions [landfield.com] archive, but i don't see it there yet.

    also, see the news item [securityfocus.com] at securityfocus about this.

    • Re:more to the story (Score:3, Informative)

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

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

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

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

      --Dan

      • Re:more to the story (Score:3, Interesting)

        by Phexro ( 9814 )
        how about "the wu-ftpd developers weren't aware that this bug was exploitable" - since it was discovered soon after 2.6.1 was released, but they decided not to fix it.

        don't get me wrong here - i don't use wu-ftpd, either. i use the openbsd ftpd [debian.org] ported to linux.

        i just felt that people should be aware that there was more to the story.
  • 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?
    • Actually I think all the vendors who agreed to delay releasing patches for a known severe problem have breached their customers' trust and should be punished. I would like to know what's going to be done to them. Maybe their customers should just stop doing business with them; that usually makes the problem go away on its own.
    • Give me a god damn break. If you had a CLUE about the facts in this case (which include incorrectly addressed email etc) you obviously would not be posting. Why not let the folks whos business this is, CERT, handle the 'punishment', and you go do something useful?

      RedHat has CONSISTENTLY done the Right Thing in a number of areas with respect to Linux. Despite a number of chances not to. This endless self-destructive attitude of the linux community, mainly centered with people who have yet to contribute a line of code anywhere I suspect, but who love waving their hand and yelling foul should stop.

      Seriously, I'd love to auto-mod down folks who don't contribute jack, but cause endless heartache on endless lists. Recently a flame war errupted when someing claiming to be one of the 10 people in the world who wanted to see the kernel improve came on and said linus should stop maintaining 2.5, despite the fact he'd yet to write a line of code for the kernel.

      Taking what trolls like this and the one above seriously undermines things.

      The irony is that the linux camp is all for full disclosure, so RH arguably did the RIGHT thing and let us all know of a problem we wouldn't have found out about till later.

  • Know what you're doing. (Score:3, Interesting)

    by rice_burners_suck ( 243660 ) on Wednesday November 28, 2001 @09:19PM (#2628131)

    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.

    • It's not like Red Hat released it deliberately, they've admitted they screwed up- everyone else was working on the fixes; right now its a race between the script kiddies and the fix grownups.

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

      That's their problem. But:

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

      No. Actually it depends on how well known the vulnerability is in the wild. If it's not well known then the chances of your box being rooted is very small. Right now there is total knowledge- the only thing that people can do is remove this service; assuming they are awake right now- heaven knows what people in India are going to do- their boxes are going to be seriously at risk.

      >In other words, if you don't know what you're doing, you shouldn't be using a computer.

      Yep, you, me and anyone else without true omniscience shouldn't be using a computer. Hardly a practical position is it?
    • It takes a little time to test things, and this errata release shouldn't have happened. We (Red Hat) screwed up, which opened up a window where the vulnerability is known and not everyone has the fix ready. Delaying it a week, as we had intended would have avoided that window of oppurtunity for script kiddies.
  • 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?

  • Shame (Score:3, Funny)

    by Syberghost ( 10557 ) <syberghost@syber ... S.com minus poet> on Wednesday November 28, 2001 @09:24PM (#2628146)
    How dare those RedHat bastards fix a security problem early.

  • Hypocrisy Detected!!! (Score:5, Insightful)

    by Pinball Wizard ( 161942 ) on Wednesday November 28, 2001 @09:25PM (#2628148) Homepage Journal
    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?!


    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.

    • 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.

      Microsoft is bashed because they take so long to release a fix that they know will work. RedHat releases a FIX immediately when they know it works.

      Which company would you rather have a support / maintainance contract with ? Yeah, I thought so.

      CERT had knowledge of the bug, a patch available, and quality assured with that patch... yet they still asked for a delay in publicizing the bug. Why ? The question should not be about RedHat, who acted responsibly, but instead why CERT is causing holdups that allow people in the underground communities more time.

      Hmm... I wonder if the FBI, NSA, or CIA is on the list of "early notifications" .... FBI intel. probably uses these early notifications

    • Re:Hypocrisy Detected!!! (Score:5, Funny)

      by fanatic ( 86657 ) on Wednesday November 28, 2001 @11:34PM (#2628796)
      Tip for MSCEs: Samba and SSH will allow you to remotely administer a Windows network better than any Windows tool.


      Actually, IIS does a pretty good job of letting *everyone* remotely administer your Windows system.

  • No surprises here (Score:5, Insightful)

    by Broccolist ( 52333 ) on Wednesday November 28, 2001 @09:26PM (#2628155)
    Wu-FTPd has had a long history of security holes. It's practically the BIND of FTP servers.

    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.

    • Re:No surprises here (Score:2, Redundant)

      by augustz ( 18082 )
      Couldn't agree more, the distros need to stop shipping software with horrendous security records.

      wu-ftpd/bind/sendmail literally give me the shudders. There are solid competitors for all of these. Greater or equal features, and designs that are much more secure.
  • 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.

  • Security must-dos for RedHat (Score:5, Informative)

    by Hoonis ( 20223 ) on Wednesday November 28, 2001 @09:31PM (#2628179) Homepage
    This shows you what daemons are auto-started:
    # /sbin/chkconfig --list | grep :on

    man NAME_OF_THING_YOU_DONT_KNOW_WHAT_IT_IS
    # /sbin/chkconfig --del THING_YOU_DONT_WANT

    get the latest nmap from freshmeat.net.
    do this:
    # nmap -sS -P0 YOURIPORHOSTNAME

    do you see any ports you weren't expecting?
    Turn off the services!

    Install portsentry + ipchains on a firewall,
    or if you don't have more than one box, your
    own box! Set portsentry to listen on bind to
    catch a lot of automated attackes from a RH6.2
    bug. Move your ssh (2.X or greater!!) daemon
    to a non-standard port (edit /etc/ssh2/ssh2d),
    then set the normal ssh port as a portsentry
    tripwire.

    Very active attacks right now:
    Bind
    ftp
    finger
    telnet
    ssh
    port 59 (anyone know wtf that is?)

    wu-ftpd had an *earlier* vulnerability that
    was causing increased scan activity too!

    Subscribe to the cert.org mailing list, and
    "grep for linux".

    you have to take an active role and pay attention
    to all security bulletins out there, because
    you will literally be attacked within an hour
    of bringing up a new DSL/T1 server anywhere in
    the wild. I've seen portscans on newly installed
    lines in less than 5 minutes!

  • ironic.. (Score:3, Interesting)

    by LinuxHam ( 52232 ) on Wednesday November 28, 2001 @09:33PM (#2628190) Homepage Journal
    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. :-/

  • To those who would cry "hypocracy" (Score:4, Insightful)

    by noahm ( 4459 ) on Wednesday November 28, 2001 @09:35PM (#2628196) Homepage Journal
    There have been a number of posts here claiming that the Linux vendors are being hypocritical by claiming to support full disclosure while maintaining a private list for the coordination of announcements regarding such security issues is this. However, they are missing the point. This list is not against full disclosure in any way. It is simply a way for vendors to coordinate their fixes before the exploit is widely published. At no point are the vendors discouraging the vulnerability's publication. They are merely delaying the announcement so they can coordinate the availability of their updates.

    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 [snort.org] 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 [demarc.org] is a web-based console for SNORT, plus a pretty good host/service monitor.

  • Tiny Violins (Score:5, Informative)

    by gnovos ( 447128 ) <gnovos@ c h i p p e d . net> on Wednesday November 28, 2001 @09:42PM (#2628226) Homepage Journal
    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.
  • 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.

  • Regarding disclosure... (Score:5, Informative)

    by slashkitty ( 21637 ) on Wednesday November 28, 2001 @09:51PM (#2628276) Homepage
    As a security bug hunter myself, I know that the sooner you disclose the sooner it gets fixed. The more serious the hole, the sooner it should get fixed. period. 2 weeks ago, I published an alert [securityfocus.com] on a bunch of website security holes, including microsoft.com. Knowing how ms reacts to disclosure, I didn't disclose the specifics on microsoft.com's site, but I did on the others. Guess what? The hole on microsoft.com is still not fixed, while most other sites have moved to fix their holes. Now, this hole also affect thousands (if not millions? ) of sites, but it seems to require disclosure to get things moving.

    Now, RedHat maybe shouldn't have ever made this "agreement" to pospone patches. Maybe they noticed that people were already making use of this not-so-secret-to-black-hats bug. Or, maybe it was just a mistake... I don't know. I'm just glad I don't have a public wu-ftp server to deal with.

  • WU-FTPD maintainer ain't happy... (Score:5, Informative)

    by MelloDawg ( 180509 ) on Wednesday November 28, 2001 @10:40PM (#2628513)
    Check out this thread on the wuftpd-questions list:

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

  • Go with something more secure. (Score:3, Informative)

    by Scoria ( 264473 ) <`slashmail' `at' `initialized.org'> on Wednesday November 28, 2001 @10:50PM (#2628563) Homepage
    As we are all aware, Wu-FTPd is insecure, buggy, and, for the most part, a thrown together hack. All of you wu-ftpders could eliminate (or at the least dramatically reduce) your problems by using one of the following:

    ProFTPd [proftpd.net]: the ftpd that I prefer most. It was designed with security in mind (wow, rhyme) and its configuration is akin to Apache's.

    PureFTPd [sourceforge.net]: a relative newcomer; said to be fairly secure. Based upon TrollFTPd.

    If you're an administrator that prefers security over convenience, you may wish to check into secure FTP or simply use SSH to transfer files. Like many "old style" daemons, FTP transmits sensitive data (namely passwords) without any type of encryption applied. Just remember: system security depends only on the competence of your administrator. Most administrators (at least myself and those that I know) refuse to touch wu-ftpd with a fifty foot pole.

  • Anyone using wu-ftpd... (Score:3, Insightful)

    by debolaz ( 526572 ) on Wednesday November 28, 2001 @10:54PM (#2628591) Homepage
    Anyone using wu-ftpd has only themselves to blaim if anything happends to their servers. This application [wu-ftpd.org] has a bug history making Microsoft look like what OpenBSD [openbsd.org] claims to be. There are many free and secure [netbsd.org] and certainly more extensible [proftpd.org] options available, so why distros still stick with wu is beyond my understanding.

  • C lang remains inappropriate for network daemons (Score:5, Insightful)

    by Tom7 ( 102298 ) on Thursday November 29, 2001 @12:19AM (#2629013) Homepage Journal

    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 [inria.fr] 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 [sourceforge.net] and an ML compiler here [sourcelight.com] . (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.

  • Why is a FTP daemon running as root? (Score:3, Insightful)

    by Animats ( 122034 ) on Thursday November 29, 2001 @01:34AM (#2629227) Homepage
    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.

  • Can kernel security patches do something against t (Score:3, Insightful)

    by chrysalis ( 50680 ) on Thursday November 29, 2001 @05:41AM (#2629830) Homepage
    To protect against unknown exploits, there are kernel patches like LIDS [lids.org] . 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.

    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 /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.

Slashdot Top Deals

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Close