OpenBSD Journal

[OpenSSH] root privilege escalation bug

Contributed by Dengue on from the damn-it. dept.

sky writes :
"A bug exists in the channel code of OpenSSH versions 2.0 - 3.0.2. Users with an existing user account can abuse this bug to gain root privileges. Exploitability without an existing user account has not been proven but is not considered impossible. A malicious ssh server could also use this bug to exploit a connecting vulnerable client.

http://www.pine.nl/advisories/pine-cert-20020301.txt "

(Comments are closed)

Comments

  1. By bob () on

    bummer.

    Comments

    1. By Anonymous Coward () on

      Actually no, this isn't a remote hole. You need local access to take advantage of the privelage escalation so four years without a remote hole stands AFAIK.

      -Vig

      Comments

      1. By Anonymous Coward () on

        Regardless of the four year mark being valid or not, this is the 3 release in a row of OpenSSH due to a local root exploit. Doesn't that bother anyone else, especially coming from a group that prides themselves (and very loudly at that) on security?

        Comments

        1. By Anonymous Cowherd () on

          Yeah, I'm really bothered. I think I'll switch to telnet.

          Comments

          1. By Anonymous Coward () on

            me too ;)

            Comments

            1. By Gimlet () on

              tn3270, baby. Hey, like any 14-year-old will figure out EBCDIC. ;)

        2. By Anonymous Coward () on

          No actually it doesn't bother me. It makes me happy that they practice full disclosure. Would you rather they try and cover it up after the fact? It also makes me happy that patches have been released *before* the skript kidiot community has had an opportunity to take advantage of it.

          Comments

          1. By Anonymous Coward () on

            You mean kinda like Theo's obfuscated CVS changes to the exploitable telnet daemon? Yeah, I'm glad they don't try to cover up stuff like that? But hey, since telnet is insecure, I'm sure no one has ever enabled it on OpenBSD, so it's really a non-issue, right?

            Comments

            1. By Anonymous Coward () on

              What are you talking about?

              Comments

              1. By thuggee guard () thuggee@ijones.com on mailto:thuggee@ijones.com

                He's blowing hot smoke up our asses I think. Feels a little tingly.

        3. By Anonymous Coward () on

          thats a great track record considering how many people audit the code looking for a way to exploit it

          its probabley the most audited piece of code on earth

          Comments

          1. By Anonymous Coward () on

            Is it really that great a track record?

            This particular bug has been there since the start. I wonder what that says about the auditting ability of those who have audited between now and then. How did it get skipped all those other times when people audited it?

            One thing's for sure: if this is the most heavily auditted piece of code on earth, we're all incredibly bad at auditing software. Well, those who have audited it are, anyway.

            I want someone explain to me why Theo didn't find this bug in one of his regular code audits. Did he never audit this particular line? If not, what other lines did he not audit? If he did audit it, how did he not recognise it was a bug? If he can miss this bug, how many others of an obscure nature have been missed?

            For all the hype that OpenSSH (&OpenBSD) generate about auditing and bug elmination, there ought not to be any security bugs/holes at all in their software. Anything less really says that this process is effectively worthless to the end-consumer, with outsiders being left to find the bugs in released versions of the code.

            Comments

            1. By Anonymous Coward () on

              I AGREE I THINK THAT FIXING SOFTWARE IS FUTILE BECAUSE YOU CAN JUST SMASH A COMPUTER WITH A CROWBAR IF ANY VULNERABILITIES EXIST THEN THERE IS NO POINT AT USING THE SOFTWARE THAT IS WHY I STILL RUN WINDOWS 95 SORRY FOR THE CAPS LOCK AND LACK OF GRAMMAR LETTERS AS MY KEYBOARD HAS LONG SINCE LOST ALL USE OF NON ALPHA NUMERICAL KEYS BUT I KNOW THAT OTHER KEYBOARDS PROBABLY HAVE MINOR IMPERFECTIONS IN THEM TO NOTHING IS PERFECT SO THERE IS NO REASON FOR ME TO BY A NEW SOFTWARE LIFE IS POINTLESS STRUGGLE IS USELESS ANY ATTEMPT WHICH PARTIALLY SUCCEEDS AT ANYTHING IS A FAILED ATTEMPT THAT IS WHY I DO NOT LOCK MY CAR OR TRY TO LEARN HOW TO COMPOSE DECENT MESSAGES ON MESSAGE BOARDS BECAUSE I KNOW THAT THEY COULD GET CORRUPTED BY SOMEONE ELSE ANYWAY I AM NOT IN CONTROL OF EVERYTHING THEREFORE I HAVE NO CONTROL THERE IS NO SUCH THING AS RESPONSIBILITY OR SUCCESS OR LIFE WE SHOULD ALL JUST ADMIT THAT WE WILL DIE AND DIE NOW BECAUSE IF WE JUST TRY TO NOT DIE THEN THAT IS THE SAME AS DYING THANK YOU SIGNED ME

              Comments

              1. By Anonymous Coward () on

                HAAAAAAAAAAAAAAAAAAAAHAHAHAHAHAHAAHHAHAHAHA
                {takes a breath}
                ehehehehehehehehhehehehehe heeeeeeee......
                {big inhale}

                woohoooo..... man I needed that.

                Thanks.

                Comments

                1. By Anonymous Coward () on

                  THANK YOU FOR YOUR UNDERSTANDING OF WHERE I AM COMING FROM AS SOMETIMES PEOPLE SAY NO GO AWAY TROLL OR AND THEY DO NOT UNDERSTAND THE FINER POINTS OF JOKING OR AND SARCASM SO I WOULD LIKE TO TELL YOU YES I AM LAUGHING VERY MUCH AT THIS MODE OF WHAT I AM SAYING TO MAKE A POINT THANK YOU YOURS DIGITALL ME P S MAN OH MAN AM I GLAD IT IS FRIDAY YES

                  Comments

                  1. By syntaktic () leila@jhu.edu on http://syntaktic.net

                    the whole mentality of "i am not in control of anything so why does it matter. life is futile" is rampant these days. and its sad. your post is hilarious yet frighteningly true. i wish more people would realize they are absolutely in ultimate control of themselves (Well except maybe the long gone crazy folk with massive brain hemmoraging but they have a doctors note and an xray to add...)

              2. By Anonymous Coward () on

                I AGREE I THINK THAT FIXING...
                ...DYING THANK YOU SIGNED ME

                dude this post is great.

                are you the "armenian cowboy" from the Darren Reed provides OpenBSD 3.0 fork w/ IPFilter. thread? that is the only more lucid post i have ever read.

                i'm quoting both of them on my website.

                Comments

                1. By armenian cowboy () on

                  NO HE IS NOT I AM

                  HOWEVER HE MAKE A GOOD POINT WHEN IT COMES TO SOFTWARES. IN CS 372 WE LEARNED THAT SECURE WILL NEVER WORK IN MARKETPLACE DUE TO HIGH COSTS AND TEEN AGE HACKS. BUT I STILL HAVE A VIPER 870S SECURE SYSTEM IN MY CAR SO I CAN DRIVE DOWN TOWN AND BE SAFE!!!! I HAVE A NICE CAR AND I DONT WANT IT STOLEN RIGHT?

                  DO YOU AGREE? WHAT KIND OF SYSTEM SECURITY DO YOU CARS USE?

            2. By Anonymous Coward () on

              You need to study how computers work and how the software is written. I was going to respond in details at first, but than realized that your knowledge base is not sufficient enough to uderstand why you are completely wrong.

            3. By Anonymous Coward () on

              Are you clueless?
              Yes.

              Do you know anything about writing system code?
              Obviously not.

              If it is so worthless, switch to W2K...

            4. By Anonymous Coward () on

              I want someone explain to me why Theo didn't find this bug in one of his regular code audits. Did he never audit this particular line? If not, what other lines did he not audit? If he did audit it, how did he not recognise it was a bug? If he can miss this bug, how many others of an obscure nature have been missed?

              Why don't you try auditing some incredibly complex software system and get back to us?

              For all the hype that OpenSSH (&OpenBSD) generate about auditing and bug elmination, there ought not to be any security bugs/holes at all in their software. Anything less really says that this process is effectively worthless to the end-consumer, with outsiders being left to find the bugs in released versions of the code.

              So because the process doesn't catch every single bug we should stop auditing? Yea... that makes sense. Might as well repeal all those drunk driving laws because they don't stop all drunks from driving.

              If you really expect *EVERY* single bug to be caught by auditing, I suggest you find another (job | hobby | whatever).

    2. By cb () boyer_c@bellsouth.net on www.openssh.com

      OpenSSH 3.1 and newer are not vulnerable to "March 7, 2002: Off-by-one error in the channel code", OpenSSH Security Advisory.

      Comments

      1. By Anonymous Coward () on

        My bad. Read Before I Post!! Read Before I Post!! Read Before I Post!! Read Before I Post!! Read Before I Post!! Read Before I Post!!

  2. By Przemyslaw Frasunek () venglin@freebsd.lublin.pl on http://www.frasunek.com

    First of all, it won't be exploitable on *BSD systems. The only threated platform is Linux with Doug Lea's malloc(). This is 4 bytes overflow on heap. Only Linux keeps heap control structures just after malloced buffer.

    Comments

    1. By DieNadel () no_sleep_till_brooklyn@nospam.spamsucks.com on mailto:no_sleep_till_brooklyn@nospam.spamsucks.com

      Hmmm, isn't that how the sudo exploit worked? By overflowing a control structure just after the buffer? Not sure, can anyone confirm Przemyslaw Frasunek's affirmation?

      Comments

      1. By Przemyslaw Frasunek () venglin@freebsd.lublin.pl on http://www.frasunek.com

        Yes, but sudo exploit works only on Linux platform. Glibc malloc is implemented as linked list, with pointers to prev and next chunk just after allocated buffer, which can be overwritten. This allows to fool UNLINK() macro in free() code. I had the same problem when developing exploit for wuftpd 2.6.1, only on modern Linux distros it was fully exploitable. Read my posts on vuln-dev.

        Of course, OpenSSH installed on *BSD platform in fact IS vulnerable, but this vulnerability can't be exploited.

        Comments

        1. By Juan Meneses () juan@iki.fi on http://iki.fi/juan/

          > Yes, but sudo exploit works only on Linux platform

          The last sudo exploit I was aware of indeed works for BSD as well. I got a root shell by using it on my OpenBSD 2.9 box running the Postfix mailer. Please stop spreading disinformation.

          Comments

          1. By Przemyslaw Frasunek () venglin@freebsd.lublin.pl on http://www.frasunek.com

            We are talking about sudo heap overflow. Just use your brain.

            Comments

            1. By Juan Meneses () juan@iki.fi on http://iki.fi/juan/

              I'm afraid you were talking about "the sudo exploit", which is quite ambiguous. Just use the terms you want people to understand.

    2. By Anonymous Coward () on

      If *BSD is not effected, then why does this advisory state that the "FreeBSD poirt of OpenSSH has been updated to reflect the patches as supplied in this document"?

      Or, LinuxSecurity Reports that the "off-by one" bug does effect FreeBSD 4.4-RELEASE, 4.5-RELEASE and 4.5-STABLE?

  3. By Anonymous Coward () on

    In response to the previous topic on how to write secure code, I sugested that it might be a good idea to write network services in languages that, if they are implemented correctly, don't have buffer attacks because they don't allow direct memory access. Java is a good example of this. I was flamed by people saying, "if you even thought about this for ten seconds you would see how idiotic that is. Just write your code correctly and do good software engineering and then there won't be any mistakes!" Hmmm. I guess we have found out yet again that even the smartest, most competent programmers in the world (ie, the OpenBSD team) do occasionally make mistakes. Maybe some methods of systematicly preventing mistakes, such as using pointerless languages, might help?

    Are there any ssh server implementations in java?

    Btw, this post is not intended to start a flamewar. I just want to point out that there may be some merit to writing net services in more secure languages. Verify the integrity of the bytecode interpreter and then any services that run within that VM will be as secure as the VM itself, right?

    Comments

    1. By Anonymous Coward () on

      Um, an ssh server in Java?

      SOUNDS COOL MAN

      Maybe we can make it use CORBA too, and some
      awesome RMI object broker to transfer some XML
      into my servlet, SIGN ME UP.

      I'm sure that will fix all our problems

    2. By fansipans () on

      i am neither physically nor mentally capable of being as sarcastic as this post requires. hmm.... what about these problems:

      1. DEFAULT PASSWORDS
      your magical hobbit ring wearing bytecode interpreter will be able to detect code designed with default passwords?

      2. user input which triggers unintentional information output
      ever sent 'debug=ong=on' to random php scripts :P, this is a great way to reveal information about a system

      3. RACE CONDITIONS ...
      how the hell is a 'verified bytecode interpreter' gonna know which order you intended to do something, if you accidentally code it with a race condition

      4. Being a complete and total f*@!ng monkey
      suppose there is a magical language (let's call it SUPERSSAFE!@!), it doesn't have pointers (oh! no memory vulnerabilities!), doesn't have objects (oh! no worrying about public/private methods/objects!), and it can't even OPEN FILES AT ALL! it only has standard mathmatical and logical operators (+,-,*,/,IF,WHILE), and the following functions:
      PRINT
      EXIT
      LISTENTOTHEINTERNET

      suppose i have a SUPER DUPER SECURE PROGRAM that has to be secure because it just listens for connections (hey! like ssh does!) and then prints out a credit card number...it looks like this:

      handle=LISTENTOTHEINTERNET
      IF handle=="JUJUFRUIT"
        PRINT "7912-1231-1234-5321"
      IF handle=="DEBUG"
        PRINT "HELLO I AM LISTENING!! LOOK HOW SECURE I AM YOU NEED TO KNOW THE SECRET PASSWORD. THIS PROGRAM IS ON. AND THE CREDIT CARD NUMBER IS 7912-1231-1234-5321"
      EXIT

      how is ANY kind of interpreter going to prevent you from being a monkey?!

      --fansipans

    3. By pravus () on

      1) security is a process. it is not something that is as easily fixed as switching to a new language. you have to look at things on a case-by-case basis, as well as look at things at different angles. for example, it is commonly said that when writing secure code, you should only use strncpy() and never use strcpy(). this, however, is not true. if you inspect code on a case-by-case basis, you will find numerous times when strcpy() is just as safe (and probably faster) than strncpy(). also, you need to look at the context of the code. overall design errors are just as bad as the small not-so-obvious errors.

      2) with the way things are currently, would you really ever be at a state where you could trust the VM? if you try to keep the VM simple, you won't have much functionality, but you would feel better about the code since there wouldn't be much, and hence there should be fewer errors than in a larger project. however, users demand functionality as well as developers. the VM would have to be robust and provide powerful commands that would add complexity to the code it was written in. more code, more mistakes, more time auditing for mistakes. also, as with everything computerized, you have the growth and maintenance factor.

      one more thing to think about with a single VM-based OS... if an exploit is found in the VM, depending upon the nature of the exploit, it might not just be exploitable in one program. you might have a bug that is exploitable in *any* of the programs that operate in the VM. the all-the-eggs-in-one-basket arrangement.

      but then again... maybe i'm a crack addict.

      Comments

      1. By Anonamoose () on

        These are all valid points. Nonetheless, I could argue that the use of C in network programs almost amounts to a design flaw. C lends itself to bugs even when used by careful and thorough programmers such as the OpenBSD team.

        In theory, switching to a different language might make programs more secure. I don't think such a language exists today (it's certainly not Java), as it would have to be designed so that the programmer still has enough low-level access in order for the program to be efficient, while at the same time making programmers work harder to hang themselves.

        Comments

        1. By stripes () stripes at the place apple give free email on mailto:stripes at the place apple give free email

          In theory, switching to a different language might make programs more secure. I don't think such a language exists today (it's certainly not Java), as it would have to be designed so that the programmer still has enough low-level access in order for the program to be efficient, while at the same time making programmers work harder to hang themselves.

          Sure they do, Modula-3 for example. The problem with most (or all!) of them is it is harder to find a runtime system for them on all platforms, more differences exist form compiler to compiler, fewer programmers understand them, and very few of the "better" languages have free compilers for them. I also think Eifel might be a good one for security work, I'm not sure it has enough low level access for everything though.

          That said I'll note that Java is actually quite fast on some platforms. I wrote a Java SSH client (with built in ANSI-77 terminal emulation!). On a Win 95 box using the Sun JVM, whatever Netscape had at the time, and whatever Symentec had at the time it was quite fast. Like I could scroll through a 500k /etc/termcap faster with my SSH client then the telnet that Microsoft shipped. Now I expect they didn't optimize their client for speed, and before I decided to see what could be done they ran about 4x faster then me, but still even then the Java SSH ran fast enough (doing 3DES!) that you would never think it wasn't C code.

          On other platforms (generic byte code JVM on BSD/OS or FreeBSD) it was slower then a dead slug.

          Comments

          1. By fansipans () on

            logic errors, race conditions, default passwords. Every language will be vulnerable. Security is an engineering problem. yes, the engineer should choose the right tool for the right job (ie not programming in assembler for everything), but he should also know how to program so that security problems don't arise (in any language). incidentally i'm of the opinion (though i wouldnt' mind discussing it) that standards compliance is a good thing, by this i mean "damn i'm glad openbsd isn't written in scheme/rexx/eiffel/insert language here" though ymmv depending on what yr intrested in..i dunno..i'd be interested to hear other peoples' ideas on standards v. fancy woowoo features

            --fansipans

            Comments

            1. By vincent () on

              along the same lines, isn't MS windows a standard that should be mindlessly adhered to under all circumstances, at all costs?

              open source, closed minds.

              cheers.
              v.

              Comments

              1. By Anonymous Coward () on

                DUDE I LOVE YOUR QUOTE CAN I QUOTE YOU ON MY PAGE!@? OPEN SOURCE SLOED MINDS !@@ IT IS THE NEW MOTTO OF CONTEXTLESS FAGGOTRY!@@&#&#

    4. By vincent () vincent at igc.ethz.ch on mailto:vincent at igc.ethz.ch

      there has been a similar thread on slashdot. a poster there suggested the use of SML for networking programs. while i can understand that using java for this task, i think he has a point there. there are a number of languages out there, which would seem more appropriate to use for software like an SSH server than a low level language like C. Niklaus Wirth's stuff comes to mind, and ML, as suggested by the original poster.

      Could somebody comment on this?

      I am not myself into secure programming, and will ignore flames.

      thank you.

  4. By oobeleck () on

    Guess I will have to go back to rlogin with .rhosts

  5. By markus () on

    ln -s AJ /etc/malloc.conf

    should help against exploits.

  6. By Anonymous Coward () on

    So, openssh is about full disclosure? lets see what the CVS log says about this patch:

    Revision 1.171 / (download) - annotate - [select for diffs] , Mon Mar 4 19:37:58 2002 UTC (3 days, 6 hours ago) by markus
    Branch: MAIN
    CVS Tags: HEAD
    Changes since 1.170: +2 -2 lines
    Diff to previous 1.170 (colored)
    off by one; thanks to joost@pine.nl

    "off by one". If I were reading CVS logs, I'd have a hard time correlating that with a security flaw. How many other security bugs lurk in their CVS repository, fixed with obscure commit messages?

    It would seem that "security through obscurity" is what's practised, heavily, by the OpenBSD team.

    Comments

    1. By jcs () on

      From http://openbsd.rt.fm/security.html#watching :

      If you understand security issues, watch our source-changes mailing list and keep an eye out for things which appear security related. Since exploitability is not proven for many of the fixes we make, do not expect the relevant commit message to say "SECURITY FIX!". If a problem is proven and serious, a patch will be available here very shortly after.

      The problem was discovered, the bug was fixed, an advisory was sent to many mailing lists, a new version of OpenSSH was released, many of the OpenBSD and OpenSSH web pages were updated.

    2. By Anonymous Coward () on

      Things aren't always what they seem.

      Log messages have little to do with security and open publication is anything but obscure.

      View colours vision.

      Comments

      1. By Anonymous Coward () on

        On the contrary, log messages need to be self explanatory. Sometimes they only need to be brief, sometimes they need to be longer. In this case, it was known, at the time, that this was a security fix so why wasn't more said in the CVS commit message? Maybe just laziness on behalf of the developers (this I can believe)?

        In talk around the traps, it appears that the security announcement was rushed forward from next week because it got "leaked" and people were starting to develop exploits already. Evidence of things being rushed is that the announcement of 3.1 went out before the website was updated.

        What this says to me is that the CVS log message was deliberately made obscure. Why? So that the security announcement "in waiting" wouldn't be compromised by the CVS commit log.

        Comments

        1. By Anonymous Coward () on

          How is it in any way obscure after it was published? "off by one" and the attribution is all anyone needs at the level of a commit message. Security announcements are a different sort of message and have to follow their own time rather than that of the source code repository.

        2. By pravus () on

          why are you looking at the CVS repository for security messages? CVS is for tracking code changes, not for announcing bugs, exploits, or security issues.

          and i can't stand all of these people who always say "oh look... the open{bsd,ssh} team found another exploitable bug and didn't tell anyone about it. they must be trying to hide something". as has been said before in many places, they fix bugs without testing exploitability. they're main design focus is on creating a secure product, but they are NOT in the security business. it's typically others who find the exploitability of bugs and then report them.

          and if you really want to go after people who are trying to cover up bug reports, go after all of the companies that are trying to get the security reporting firms to switch to non-disclosure. those are the people who are trying to pull the wool over your eyes when it comes to security.

          Comments

          1. By Not Really Anonymous () on

            I agree with you. I would rather a team/group pro-actively fix issues rather than trying to strong arm the security community into being quiet about it.

            Do you think the underground community ceases to make exploits, just because the rest of the world doesn't _publicly_ know about it?

    3. By Anonymous Coward () on

      "Security through obscurity"? It was posted on the front page of Slashdot! How much less obscure can you get?!?

      Comments

      1. By Anonymous Coward () on

        Well, they could have had a CNN press conference with dancing girls and all. That would be nice.

        Comments
        1. Comments

          1. By Anonymous Coward () on

            DUDE TOTALLY ALL I NEED IS COUNTERSTRIKE AND WINDOWS WALLPAPER WITH BIG TITS ON IT!@$$!@!!

    4. By Anonymous Coward () on

      Darren, is that you????

  7. By Anonymous Coward () on


    OpenSSH: putting the "OPEN" back in networking

    OpenSSH: making "root" open to all

    The real question is, why have there been more security announcements and bug fixes in OpenSSH than the commercial SSH? Begs the question of whether this development process is really adding any value or just security bugs - which get fixed at some later point in time.

    Comments

    1. By Anonymous Coward () on

      There are more announcements and fixes in OpenSSH because it is open source and more recent in development than commercial, trademarked ssh.

      Comments

      1. By Anonymous Coward () on

        Are you saying that the same bugs are present in the commercial version of ssh? If you are, how come people haven't posted to bugtraq saying "exploit in openssh also in ssh"? I'm sure that kind of thing has been tested by someone and I doubt if it would have been kept quiet.

        F-Secure publish advisories, when necessary, to address security holes in their product.

        One way to read your comment is that "because openssh is open source there are more bugs requiring more fixes". Given that the real ssh has progressed to 3.1 (before openssh), any argument about there being more development in openssh is specious at best.

        Comments

        1. By Anonymous Coward () on


          Good God.

          So, given I release MySSH 4.7 tomorrow, it's better and has more features?

          Go read what's new in commercial SSH 3.1 compared to their latest 2.4. If you find anything that anyone would want to pay for, post it here.

          Oh, and as for the "record": just look at the past. Do a lookup in CERT for just "SSH". Look at the number and classification of the holes in the different implementations. And think again.

          Comments

          1. By Anonymous Coward () on

            Vulnerabilities with SSH (as found with a
            search on ssh at www.cert.org):

            7 OpenSSH only
            7 Protocol dependant (protocol v1 bugs)
            3 SSH only
            1 Shared (SSH + OpenSSH)
            1 Solaris specific (SecureRPC, SSH only)

            Comments

            1. By fansipans () on

              lines of code available for auditing for OpenSSH: 45000+
              lines of code available for auditing for commericial SSH: 0

              Comments

              1. By Anonymous Coward () on

                Lines of code available for audit in ssh:
                3.1.0 (LOC in .c & .h) 269,147
                1.2.33 (LOC in .c & .h) 74,720

    2. By Anonymous Coward () on

      Ok, Darren. You can stop now.

      Comments

      1. By Darren () on

        too bad for you that it wasn't me. I have a very
        good idea about why the openssh 3.1 release was
        so screwed (the timing between it and when i sent
        an email to a someone else couldn't be just a
        coincidence).

        although, I am concerned about the implications
        of what's been said here in defence of openssh:
        we only announce security alerts when we know
        an exploit exists (or is possible?).

        IMHO that makes the openssh team just as bad as
        any of the commercial vendors.

        it also implies there are lots more security bugs
        which get fixed "quietly" and that gives me even
        less confidence in the quality of any praticular
        openssh release.

        'nuff said.

        Comments

        1. By Anonymous Coward () on


          Please look at the advisories the team has released in the past. Plenty of times it's been a "no known exploit exists".

          What you're basically saying that every time any type of bug is fixed, you release a goddamn bugtraq advisory?

          Do you?

          Comments

          1. By Anonymous Coward () on

            nononono.... Darrentraq (tm) hehe

          2. By Anonymous Coward () on

            What if a security bug gets fixed in OpenSSH 3.1
            tomorrow. No security announcement is made.
            Some hacker, watching CVS notices the change and
            develops an exploit and keeps it quiet.
            There is no security announcement made because as
            far as the developers know, nobody is at risk.
            I cannot believe anyone would justify that
            position. Especially anyone who uses openssh.

            Comments

            1. By Sir Chevel D. Haughton III () on

              what if theo et al. plant trojans in all of the binaries for openbsd?!?@?! OH NO!@ LET US RUN BACK IN TOE TEH JUNGEL AND EAT GRUBES AND MAGOTES! EVERY DEVAELOPER MUST BE LICENSED AND CERTIFIED BY TEH INTERNETS INGINEERING TASK FORCE FOR TEH PURPOSE OF DEVEOLOPING SOFTWARE AND THEY WILL BE SUBJECTS TO CODE AWDITS AND TEH HIDERS OF BEUGS WILL GO TO JAEL!!!!@@222@!

    3. By Anonymous Coward () on

      Have you audited the code?

      Have you fixed any bugs in it?

      People with this "it's a stupid error, there's no excuse for it" mentality obviously don't know what they are talking about. It seems to me that since this off-by-one error never crashed an sshd process on any of the systems I've ran it on that it'd be a hard bug to realize was even there.

      Code auditing is a cyclic process, you start with what you see, then you look again. Every audit will miss something, that's why you re-audit, and re-audit again. You can not prove that program doesn't have bugs, only that you don't know of any bugs. You just have to keep looking.

    4. By Anonymous Coward () on

      d'uh.

      Can you say OpenSSH has replaced most instances of Commercial SSH?

      Who in their right mind will support the commercial veriant when you can spend your time developing a reputable Open-Source product?

  8. By Anonymous Coward () on

    http://www.openbsd.org/errata.html is not updated....

    So people only watching that is not warned!!!!!!


    Comments

    1. By Anonymous Coward () on

      Why The Fuck Does They No Update That Site And The Source In CVS!

      cvs -q get -P src
      and then recompile SSH would be nice....
      easy and simple

      BUT NO, it isn't updated yet!!!!

      Comments

      1. By pravus () on

        and i guess the openbsd team is there to make your life simple? do you or anyone else you know pay the openbsd team to specifically keep the website updated with the most current security information?

        get a life. if you are only relying on openbsd's website for security information, you do not need to be administrating anything. the disclosure about the bug AND a patch has been widely discussed in many places over the past few days. i really feel sorry for you and your users if you can't find and download the patch to fix your system.

      2. By Anonymous Coward () on

        screw off retard!!

      3. By Anonymous Coward () on

        cvs was updated within hours, long before you posted this crap here. I already rebuilt ssh on four servers by the time your posted here. Either you need to switch to the more frequently updated cvs mirror, or get some brains. (or both)

      4. By Not Really Anonymous () on

        If you want "easy and simple" switch to Microsoft.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]