Follow Slashdot stories on Twitter


Forgot your password?

OpenSSH Local Root Hole 554

maelstrom writes: "Looks like someone's found a local root exploit for OpenSSH versions between 2.0 and 3.0.2. Seems as though its a one-off error, there is no public exploit, but there is sure to be one shortly. They aren't ruling out remote exploit. Recommending patching and upgrading ASAP."
This discussion has been archived. No new comments can be posted.

OpenSSH Local Root Hole

Comments Filter:
  • More Proof (Score:3, Interesting)

    by SquierStrat ( 42516 ) on Thursday March 07, 2002 @12:29PM (#3124818) Homepage
    This is just more proof that nothing is 100% secure. :-) How does that saying go, if it can be devise it what? Some want to finish that for me?

    Regardless of that though, I get on my knees and thank God everyday for SSH. It's saved me many many many hassles from simply forgetting to turn it off on computers on my home's network.
    • Re:More Proof (Score:2, Interesting)

      by Anonymous Coward
      Does it bother anyone else that the last THREE releases of OpenSSH were because of discovered holes? Not very encouraging from a group of induhviduals who like to pride themselves (and very loudly at that) on security.
      • Re:More Proof (Score:4, Insightful)

        by SquierStrat ( 42516 ) on Thursday March 07, 2002 @12:36PM (#3124879) Homepage
        I'm sure it's more than the last three. Really, how many new features does SSH need? Bugs in an application of this type that is as mature as SSH tend to be security related. It actually makes me feel better that they're quickly responding to security bugs and doing new releases because of it.
  • Commercial SSH (Score:3, Insightful)

    by Stavr0 ( 35032 ) on Thursday March 07, 2002 @12:32PM (#3124840) Homepage Journal
    Does the same issue exist in Commercial SSH? The advisory makes no mention of it.

    I assume it wouldn't be as it's on a different code base, then again 'assume means making an ASS out of U and ME'

  • by MarkusQ ( 450076 ) on Thursday March 07, 2002 @12:35PM (#3124874) Journal
    Seems as though its a one-off error

    One-off: Something done intentionally but with no intention of repeating; a custom product, sample, or prototype.

    Off-by-one error: An error in enumeration, such as starting or ending a count at the wrong value (e.g. 0 vs. 1), counting the starting/ending value in a cycle twice or not at all (e.g. in counting a group of people which includes yourself), counting delimiters as opposed to the items delimited (e.g. the "fence post" problem), or any analogous error.

    These are rather different! When I read the abstract my first thought was "how can they determine that?"

    -- MarkusQ

  • by milesbparty ( 527555 ) on Thursday March 07, 2002 @12:36PM (#3124880)
    Systems Affected

    IBM AIX versions 4.3 and 5.1
    Hewlett-Packard's HP-UX
    SCO OpenServer 5.0.6 and earlier
    SGI IRIX 3.x
    Sun Solaris 8 and earlier


    Several implementations of direct serial connect console may have a serious security hole. In more than several cases, a guy (SA) sitting on a folding chair in a data center, directly logged in to the system via serial connection and dumb terminal, was hit over the head with a stick by another guy. The second guy was then able to gain access to the system by forcefully taking away the dumb terminal from the guy that was hit over the head, and use his login to do bad stuff on the system.


    The guy that was hit over the head with the stick suffered a bump on the head, and bad stuff was done on the system.


    We recommend disabling ALL systems in your data center. Issue the following command on Solaris: init 5, then turn it off by toggling the on/off switch. This method will prevent any attack outside your network, from within your network, and by god, from within your data center. The is the best known method of stopping ALL security holes, including the "stick on the head" issue. As vendors report new information to the CERT/CC, we will update this section. []
    • by Anonymous Coward
      Oh NO! I hope no one hacks my mighty Personal IRIS workstation! In the wrong hands, its power would be terrible...
    • I think this advisory has been comprimised, because the solution doesn't fix the problem.

      Doing an init 5 on a Solaris box will gracefully shutdown the box, and power it off. If you toggle the power switch after that you're just turning the box back on.
  • by Noryungi ( 70322 ) on Thursday March 07, 2002 @12:36PM (#3124882) Homepage Journal

    Here is what can be found on their web site:

    "OpenSSH 3.1 released March 7, 2002."

    Hmmm... That was quick! Especially since the advisory reads:

    Pine Internet Security Advisory

    Advisory ID : PINE-CERT-20020301
    Authors : Joost Pol
    Issue date : 2002-03-07
    Application : OpenSSH
    Version(s) : All versions between 2.0 and 3.0.2

    Pretty good job.
    • The vulnerability was sent to the OpenSSH team a few days ago. It was not publicized until a fix was in CVS.

  • by bill_mcgonigle ( 4333 ) on Thursday March 07, 2002 @12:37PM (#3124885) Homepage Journal

    For you guys too lazy to read: xt []
    ( I was going to post the patch here, it's really small, but apparently slashcode doesn't know what the blockquote tag is for, despite claiming it's supported)

    But this isn't just an attempt at karma whoring, there is a point. When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that Microsoft secured their software over the last month?

    • When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that C is the right language to do coding in?
  • by Russ Nelson ( 33911 ) <> on Thursday March 07, 2002 @12:38PM (#3124892) Homepage
    I can't wait for the Daniel J. Bernstein version of ssh.
    • by Anonymous Coward on Thursday March 07, 2002 @12:55PM (#3124999)
      you mean the one that requires you to set up 3 accounts for the client, 3 accounts for the server, and comes with its own inetd replacement?
      • you mean the one that requires you to set up 3 accounts for the client, 3 accounts for the server, and comes with its own inetd replacement?

        You forgot the part about the code being totally undocumented (including no descriptive variable names whatsoever) and that it will only securely talk to djbssh clients since ssh is a useless tool of a protocol that should have never been passed as in RFC. :-)

        qmail is an awesome program. Too bad it's almost impossible to understand the code. :-(

        • It's not as bad as all that. First, there just aren't so many global names that you need to have them be descriptive, but they are reasonably so anyway. flagcritical is set when you're in a critical section of the smtp dialogue.

          Most of the global names are quite descriptive, e.g. byte_copy(). What does it do? Copy bytes. case_lowers()? Lowercases strings.

          It's really not that bad once you spend a bit of time on it.
      • by Crag ( 18776 )
        If there were such a thing, it would use ucspi-tcp, not an additional inetd replacement, and like qmail. Ucspi-tcp provides functionality that inetd doesn't, and maintains the "connection handling" vs "services" separation that inetd provides. It is a natural step to replace parts which do not provide whatever is needed, and to reuse those parts.

        Also, qmail's division of the jobs into multiple independant modules makes security analysis and improvement of the whole package much easier. Every module is completely and explicitly documented in man pages and numerous web pages, so even a less advanced programmer like me can write a wrapper for a module to add funcionality to. The risk of unexpected consequences is FAR lower because modules have their own UIDs.

        If there's a good reason for it, why not do it?
    • by biot ( 12537 ) on Thursday March 07, 2002 @12:59PM (#3125030)
      It would be incompatible with the rest of the world's ssh implementations, of course, but I guess he'd write a DJB-RFC to take care of that.
  • by Tom7 ( 102298 ) on Thursday March 07, 2002 @12:47PM (#3124957) Homepage Journal
    This kind of bug would NOT BE EXPLOITABLE if sshd was written in a modern safe language.

    If the canonical secure software from the canonical secure software people has bugs like this, I don't see how anyone can argue that it's possible to write secure code in C. C makes it easy to make this kind of bug, and the bugs are often exploitable.

    Check out my previous post and ensuing discussion on this 013 [] for more info. Synopsis: There are some reasons to use C for a project, but none apply to network daemons. As a proof of concept, I rewrote FTPD in my favorite modern language; the source went from 24,000 lines to 3000 (including support code, like PAM_MD5 password encryption), took me only a weekend to write, and is 100% buffer overflow / format string / heap corruption free.

    I'm trying to raise awareness about this because I think it's a real obstacle to us having secure software.
    • by MartinG ( 52587 ) on Thursday March 07, 2002 @01:00PM (#3125033) Homepage Journal
      How did it cope with 18,000 simultaneous connections? Did you use mmap(), sendfile() and friends on linux to get the best performance possible? How did the xfer rates compare?

      BTW, 24,000 lines is a hell of a lot. If you want to compare like for like, have a look at vsftpd by Chris Evans. It's written entirely in c. Have a read of the source - it's quite interesting how it has been done. I would be surprised if you could find a buffer overflow.

      I actually do agree with your points mostly, but I would say "Don't use c for network apps unless you have a good reason to" and also "don't use c for network apps unless you _really_ know the hazards"

      In some ways SSH is a special case anyway. It has all the intensive maths stuff to do for the session key generation etc. Not a good idea to code that in (eg.) perl imo.

      BTW, out of interest, what is your "favorite modern language" ??
      • by wiredog ( 43288 ) on Thursday March 07, 2002 @01:06PM (#3125077) Journal
        Has all the features any Modern Programmer could want. And it has the Highly Secure .net framework built in. What more could you want?
      • by Tom7 ( 102298 ) on Thursday March 07, 2002 @01:41PM (#3125392) Homepage Journal
        > How did it cope with 18,000 simultaneous
        > connections? Did you use mmap(), sendfile() and
        > friends on linux to get the best performance
        > possible? How did the xfer rates compare?

        I can't handle 18,000 simultaneous connections, but I don't think that 99% of people actually care about that. In fact, I don't think linux even supports 18,000 open file descriptors at the same time. My ftpd is intended for the home user who cares more about getting rooted than the low-level performance of his servers.

        Yes, it uses sendfile to transfer files when it doesn't need to do EOL conversion. I'm easily able to fill my 100Mbps connection without breaking a sweat either way. (In my informal benchmarks, my server got exactly the same transfer rates as wu_ftpd).

        > I actually do agree with your points mostly, but
        > I would say "Don't use c for network apps unless
        > you have a good reason to"

        Well, ok, but what would be a good reason to?
        One might be that you need to write a server that can really handle 18,000 connections. (Then, I hope that the users of your server have enough cash to pay someone to maintain them, apply security patches, etc.)

        > In some ways SSH is a special case anyway. It
        > has all the intensive maths stuff to do for the
        > session key generation etc. Not a good idea to
        > code that in (eg.) perl imo.

        Yes, that's true. SSHD probably uses much more CPU than a typical network app. Yet (see my other posts), it really doesn't use that much anyway.

        I wouldn't suggest writing it in perl, since perl has its own kinds of easily exploitable bugs. Also, the performance of perl is not in the 20%-100% category that I mentioned. ;)

        > BTW, out of interest, what is your "favorite
        > modern language" ??

        Standard ML. It's got loads of cool features like higher-order functions, polymorphism, datatypes, parameterized modules, and static typing (which also really helps to catch bugs). It's natively compiled and quite fast. You can learn about it at Hacker types might like O'Caml better, that's at
    • by coyul ( 119455 ) on Thursday March 07, 2002 @01:03PM (#3125051)
      Did you even look at the patch?

      --- channels_old.c Mon Mar 4 02:07:06 2002
      +++ channels.c Mon Mar 4 02:07:16 2002
      @@ -151,7 +151,7 @@
      channel_lookup(int id)
      Channel *c;
      - if (id < 0 || id > channels_alloc) {
      + if (id < 0 || id >= channels_alloc) {
      log("channel_lookup: %d: bad id", id);
      return NULL;

      You want to explain to me how any "modern safe language" is going to stop me from saying 'greater-than', when I really mean 'greater-than-or-equal-to'?
      • by abaptist ( 56770 ) on Thursday March 07, 2002 @01:13PM (#3125153)
        If you look further down in the patch, it then references an array with offset 'id'. In a language like Java this would throw an ArrayIndexOutOfBounds exception, NOT read random memory and possibly cause a crash.

        So in fact a stricter language would fix this problem.
        • Someone please moderate the parent up! I could repeat what it says and karma-whore but I'd rather help the poster get his intelligent argument promoted!
        • further down... it then references an array with offset 'id'

          Has anyone been able to catch this error with a tool like Purify? Language arguments aside, the reality is that the program is already written. In my experience, debugging a complex existing program with good tools is easier than writing the same program from scratch.

      • by Tom7 ( 102298 ) on Thursday March 07, 2002 @01:16PM (#3125195) Homepage Journal

        Yes, I read it. The bug is that they write outside the end of an array.

        A modern language would not catch this bug (unless you were using a data structure like a search tree instead of an array). However, it would make it NON-EXPLOITABLE, because a safe language would cause an error (ie, exception) on an out-of-bounds write, not corrupt the heap or stack and allow for an exploit.
    • Phew! Thought i`d wasted the last 5 years of my professional life using the wrong language!
    • This kind of bug would NOT BE EXPLOITABLE if sshd was written in a modern safe language.

      Should be rewritten to say:

      This kind of bug would NOT BE EXPLOITABLE if programmers were taught to write provably correct code.

      In The Art of Computer Programming Donald Knuth discusses algorithm analysis, which I believe should be required reading before anyone is allowed to write code professionally. His techniques transcend the language in which the program is written - they are universally applicable. I doubt this exploit would exist had the programmer done a thorough review of his code. Unfortunately, algorithm analysis is becoming less and less in vogue as new HLL's make braindead coding easier - so expect to see many more of these types of errors in the future. The problem is not the language, but the programmer. The fact of the matter is that if the language is powerful enough to get real work done, it has enough power to introduce security holes into the system.* It's not a failure of the language; it's a failure of the programmer.

      Seriously, folks, when are programmers going to learn that there's more to the art than just cobbling together statements until they compile? How many exploits will it take?

      * Sure, you can't write unsafe code in java, but then again, you can't write anything useful with it either - without disk access, I doubt you'll be able to check passwords....

      • by dvdeug ( 5033 ) <dvdeug@e m a i> on Thursday March 07, 2002 @05:11PM (#3127021)
        This kind of bug would NOT BE EXPLOITABLE if programmers were taught to write provably correct code.

        In C? Please show me an example of this done.

        Even in Ada, a programming language designed to possible to prove formally correct, most people don't use tools like SPARC (the formally provable Ada subset) because it takes too long and it's too much work.

        In The Art of Computer Programming Donald Knuth discusses algorithm analysis,

        There's a big difference between algorithm analysis and formal proving, and the first is much easier. And you'll note that Donald Knuth has had bugs found in the code in his book.

        It's not a failure of the language; it's a failure of the programmer.

        And most accidents are the fault of the driver, and not the car, but we still install airbags and seat belts. Changing the language will fix some errors; given that programmers will fail, it seems wiser to prevent those errors rather than berate programmers more.

  • by Sludge ( 1234 ) <slashdot&tossed,org> on Thursday March 07, 2002 @12:52PM (#3124976) Homepage
    I use Debian Potato. These kinds of exploits are documented before packages appear for my servers. In fact, I don't think there's an update available for the PHP remove vulnerability [] documented on February the 28th, yet.

    What am I supposed to do? Break the package dependancies on the five machines I administrate and recompile new software? Or, is Debian going to support this old, clunky distro (there is no stable replacement quite yet).

    • by Ray Dassen ( 3291 ) on Thursday March 07, 2002 @01:06PM (#3125076) Homepage
      The PHP vulnerability has been addressed - see DSA 115 [].

      This SSH hole does not apply to the version of OpenSSH in potato (it's at 1.2.3-9.4; this hole is in 2.0 - 3.0.2); for woody and sid, the SSH maintainer has already uploaded new packages (see the BTS []).

    • by faedle ( 114018 ) on Thursday March 07, 2002 @01:08PM (#3125098) Homepage Journal
      You obviously don't know about The PHP problem was fixed within hours of being reported on the debian-security list, and the appropriate package was put up for apt-get'ing on March 3.

      Everybody who runs debian (especially stable or older) should have in their apt-get table. Put a line like:

      deb contribnon-free

      in /etc/apt/sources.list.

      Note that as of this writing, no updated SSH package is available.. but if previous behavior is any indication of future performance, it should be there soon.

    • Make a replacement package yourself, using a 6th test/compile box... making deb's isn't hard, haven't made rpm's so I can't say on that front. That way, you can keep convience and package managers, but change what you need to - and might come in handy if you ever want to mantain a package for debain proper instead of just a local cluster of systems..

      I don't think I'm the only one who has a test only system, to me, installing new stuff on a box that I try to keep usefully running is crazy.. of course, unstable has made me careful :)
    • > I use Debian Potato. These kinds of exploits are documented before packages appear for my servers.

      Yup; welcome to the world of binary packages where it takes a lot more than running merge and a cvs commit to fix anything.

      This is where having the base OS checked out of cvs(up) helps, cos you just get a few k of delta not an entire new binary that has to be compiled and tested heavily lest it break a dependency :)

      > What am I supposed to do?

      Assuming it's not yet on (someone else mentioned this solution) do:

      apt-get source ssh
      apt-get build-dep ssh

      Patch the source as normal, then:

      dpkg-buildpackage <source dir>

      Note: it's been a while since I used Debian, so these may not all be the exact commands, but the basics should be the same; use apt to grab the source (you need deb-src lines in your sources.list; just repeat your normal deb lines if they're not there), then the source dependencies, patch the source then rebuild the deb.

      Once you've got the new deb, put it on your shared package repository and apt-get update && apt-get upgrade all your machines, or copy them around manually and dpkg -i it.
  • OpenBSD upgrade. (Score:4, Informative)

    by saintlupus ( 227599 ) on Thursday March 07, 2002 @01:00PM (#3125035) Homepage
    OpenSSH 3.1 was released this morning. The info and tarball for OpenBSD systems is available at:

    Mine's compiling now.

  • Help yourselves: []

    SSH 3.1p1 RPM's compiled without gnome-askpass, everything else is default vanilla.
    • by SomethingOrOther ( 521702 ) on Thursday March 07, 2002 @01:11PM (#3125124) Homepage

      Isn't it a bit dogey just grabbing and installing a binary (rpm) from an untrusted source (ie you) for security software like SSH ?

      I'll get my source code from a reputable mirror and compile it myself thanks.

      • Yup, but there are folks here who know and trust me. =)

        If you're concerned, just don't download em.
    • BTW for those who want to do this themselves it's not hard. If you have a server without gnome libs installed you need to do it this way:

      rpm -ivh openssh-3.1p1-1.src.rpm

      then edit /usr/src/redhat/SPECS/openssh.spec
      and set the options as you like, in my case I changed the 0 to a 1 where the gnome-askpass bit is.

      Then use rpm to build it, cd to the SPECS directory on your system (may also be /usr/src) and do:

      rpm -bb openssh.spec

      Then watch the messages at the end which tell you where the finished RPM's are. Usually ../RPMS/i386/

      For those who want the gnome-askpass, just do

      rpm --rebuild openssh-3.1p1-1.src.rpm
  • by Dom2 ( 838 ) on Thursday March 07, 2002 @01:01PM (#3125043) Homepage
    Unfortunately, I can't post the advisory here due to the lame lameness filter. But here are the patches: A- 02:13/openssh.patch eBSD/CERT/patches/SA- 02:13/openssh.patch.asc

    Execute the following commands as root:

    # cd /usr/src
    # patch < /path/to/sshd.patch
    # cd /usr/src/secure/lib/libssh
    # make depend && make all
    # cd /usr/src/secure/usr.sbin/sshd
    # make depend && make all install
    # cd /usr/src/secure/usr.bin/ssh
    # make depend && make all install

    If you've got the ssh port installed, check out the advisory for details on what to do: +c urrent/freebsd-announce
  • I don't see any mention of non-suid clients in the advisory? Does any fellow /.er know if such clients are vulnerable to escalation of privileges?
  • Since I'm probably not the only bonehead out there in this situation, could someone more knowledgable than me advise on proper procedure for upgrading OpenSSH on a remote server via an ssh connection?

    My server runs 2.2.0p1. I've got the 3.1p1 source and I'm ready to go. I'm always afraid that a glitch in the build procedure - or even a success - could replace the existing 2.2.0p1 sshd binary while it's talking to me and cut me off, and if something goes wrong in the process, leave the server unreachable, which means a long drive to the colo facility to sit down with a keyboard and monitor.

    Can anybody help? I've never been able to find a clear answer for this question.

    • by Bluecoat93 ( 140994 ) on Thursday March 07, 2002 @01:23PM (#3125275) Homepage
      Known to work on Solaris, OpenBSD, and Linux. YMMV elsewhere, but it should work fine.

      1) Use SSH to log into your server.

      2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.

      3) Run 'ps -ef | grep sshd' or 'ps auxw | grep sshd' (depending on your UNIX flavor)

      4) find the sshd instance with a parent process ID of '1' -- this will be the actual daemon spawend by init. The other process will be the one spawned by sshd itself to handle your connection.

      5) kill

      6) the parent sshd process will terminate, but yours will stay running

      7) start up the new sshd

      8) from another workstation or window telnet to port 22 on your server and verify that the version number reflects the new version.

      9) from another workstatino or window, ssh into your server to make sure you still have access.

      10) close your original ssh session

      I've used this exact process to upgrade many machines at remote locations. As long as you verify that the new sshd is running before you close your existing connection, you should have no problems.
    • Sure I do it all the time, I'd suggest install the newest openssl first. Then unpack openssh and cd into the dir:

      ./configure --with-md5-passwords --etc etc etc, configure options here
      cat /var/run/
      kill <pid from above command>

      This kills off the master ssh process, you will still stay connected, just don't kill off any other ssh processes.


      make install
      /usr/local/sbin/sshd (or wherever you installed it to start it up)

      Don't dissconnect yet! Try sshing in again and see if the machine is accepting connections, if not, you might have to try giving it different ./configure options, like --without-pam, --ipv4-by-default etc

      If it's your first time try it remotely, you might not want to do this on a server that's a 3 hour drive away. :) FYI, I've already upgraded 3 servers this way just 30 minutes ago, still have many more.... :(
  • by umoto ( 19193 ) on Thursday March 07, 2002 @01:19PM (#3125227) Homepage
    Two weeks ago my Mandrake box, connected to a cable modem, was rooted. The only port open to eth0 was ssh (openssh-3.0.2p1). I analyzed the logs and they indicated someone had spent an hour trying to exploit various SSH bugs that have been fixed in the past. Then there was an 8 minute pause before "linsniffer" was installed and eth0 went into "promiscuous mode".

    I haven't been able to verify openssh-3.0.2p1 was truly the cause, but it seems likely. This may have been the remote root exploit which the advisory "does not rule out".
    • Couple things (Score:3, Insightful)

      by clump ( 60191 )
      The most important thing to realize is that when a machine is comprimised, it cannot be trusted. You may think that you were running only OpenSSH but you may have been runnning other services started a long time ago. I would be curious to know what kind of logs you had to go by to see what this attacker did. Slightly-smart ones clear every trace.

      Also of note is that this particular advisory is known only to affect local users. I don't think this particular bug is the cause. It may have just been a friend shoulder-surfing.

      If you want to do analysis on a cracked machine, you should place the hard disk into a different machine and examine the contents.
  • Given that [] just released v3.1 to fix the exploit.

    And I thought it was just about time to go home too. Now I'm warming up my compiler... :-(

  • No need to give up (Score:2, Insightful)

    by Fritzy ( 564827 )
    As I scan through, I see several posts of people giving up hope, and even those showing signs of dispair because they have an ssh server that they don't want to remove that service from. Fear not my friends. Simply download the rpms (openssh, openssh-askpass, openssh-clients, openssh-server) and give it an old rpm -iU openssh, openssh-askpass, openssh-clients, openssh-server It'll update everyting for you /and/ restart your services real quick. Or, if you feel like being a man, you can compile the sucker, and copy over the older versions and restart the services manually. Either way, there is no need to dispair. You're not going to lose your ability to serve ssh securely to your users. Of course, this comes as no news to most of you, but just wanted to explain it to the people who didn't seem to understand.
  • How many exploits can one "secure" softare package have? I mean jesus, BSD is fairly secure and this project is supposed to have BSD style security checks. What went wrong.

    Information like this makes me

    A. Consider purchasing SSH from a commercial source because the AMOUNT of problems with it is less

    B. Going back to telnet!

    Not many people out there with sniffers between my box and my connection. Lots of l33t haX0rS with worms probing port 22.

    • Think back to the recent /bin/login CERT advisory. Telnet and the R-services use /bin/login. Telnet was, therefore, exploitable on many boxes.

    • Or use Kerberos (Score:2, Interesting)

      by fw3 ( 523647 )
      Kerberos [] developed at MIT and used in many (most?) large-scale production systems. Source [] available.

      Kerberos has been around since '88, opensource (MIT license). It is not developed at the breakneck pace of the more modern SSH and to my knowlege has had fewer exploit bugs in 14 years than the assembled flavors of (commercial *&* open) SSH have exhibited in the last 2 years.

      Krb5 is not slick as SSH, you can't use it for a poor-man's VPN; it uses a more expensive cypher (3DES) for both auth and fully encyphered network connections. Rsh, rlogin rcp all available with strong encryption. It's not as easy to setup, nor well suited to very small networks but for my money where applicable it's a far more solid solution.

      And yeah OpenSSH's seriously checkered security record has done very little to make me think of applying OpenBSD .. thoughts?

  • by pmf ( 255410 ) on Thursday March 07, 2002 @01:53PM (#3125486)
    After analysis, I can say, that this vulnerability is 4 bytes heap overflow, VERY hard to exploit. Problably only Linux will be affected, because Doug Lea's malloc() depends on control structures located just after malloced buffer.
  • MacOS X (Score:2, Interesting)

    by jjeffrey ( 558890 )
    MacOS X 10.1.3 (latest version as of now) includes OpenSSH 3.0.2p1. I wonder how long before Apple get a patch out... I don't really want to rebuild from source on MacOS X, even though it did only take 5mins to build 3.1p1 on my FreeBSD firewall.
  • Over the course of my years of slashdot reading, I have noticed that while many are quick to point out interesting tidbits on the negative aspects of OS's, Software, and Hardware. While these reviews and notes are useful, it seems that nothing is as unbiased as it might seem.

    MS exploits often announced on here (yes i like to know about them) and in this case open's dev team mistakes are also what I consider news, however I cannot remember the last time anybody pointed out the dangers of RedHat. While every new version of a linux distro is waved about with great expectations and cheer, other OS's are actually being analyzed for the bad as well as the good. I won't say that nobody posts unbiased articles, and I will even admit that if every stupid needless redhat exploit were listed on slashdot, RedHat would look as bad as Windows. Almost every OS and piece of network software has exploits, and very VERY few developers ever get it right the first time. I just wonder why it's so easy to see all of the mistakes for software that we may not (choose/want to) use while pretending all those dozens of RedHat exploits we had to patch never really were a problem.

    Those who even bothered to reply to this newsworthy post with openbsd-bashing, are the ignorant monkeys of the open source community and have obviously never really compared UNIX's in the server world.

    Those who bothered to reply to this stating that C is the wrong language to code in bring up minor points and expect the code that drives the internet to change. C is small cpu load and if it turns out buggy, it is the developers fault. But to expect software developers who write based upon existing libraries and code concepts they have developed over decades of work to stop and try writing their apps in an experimental (and YES, pretty damn potentially exploitable itself being so new) language is just silly. PHP is "a modern language" and was just recently found exploitable despite years of development in the PHP arena. IMAGINE the chaos if the development language that your OS/net apps were written in was found to be buggy? To date I have not had to download a new version of gcc and recompile my OS/kern/3rd party apps due to a "C vulnerability". Using experimental non-prooven ( 10 years?) languages for OS/kern/apps is a pretty stupid risk.
  • OpenSSH? (Score:2, Funny)

    by Anonymous Coward
    When they said OpenSSH I didn't think they were so serious...

"The pathology is to want control, not that you ever get it, because of course you never do." -- Gregory Bateson