Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security

OpenSSH Vulnerability Disclosed, Version 3.4 Released 339

Posted by timothy from the quick-turnaround dept.
Dan writes: "OpenSSH 3.4 has been released and will be shortly available on all mirrors. All versions of OpenSSH's sshd between 2.9.9 and 3.3 contain an input validation error that can result in an integer overflow and privilege escalation. OpenSSH 3.4 fixes this bug." And kylus writes: "The previously mentioned vulnerability in OpenSSH has been disclosed by ISS X-Force today on the BugTraq list. This is a potential remote root compromise, and while there is a workaround, it's advised that users upgrade to version 3.4 as soon as they can."
This discussion has been archived. No new comments can be posted.

OpenSSH Vulnerability Disclosed, Version 3.4 Released More

OpenSSH Vulnerability Disclosed, Version 3.4 Released

Comments Filter:

  • Workaround here: (Score:5, Informative)

    by codewolf ( 239827 ) on Wednesday June 26, 2002 @11:06AM (#3769926) Homepage
    locate the "ChallengeResponseAuthentication" line in /etc/ssh/sshd_config (typically) change to :
    "ChallengeResponseAuthentication no" and restart sshd

    • Re:Workaround here: (Score:2, Insightful)

      by f00l ( 51322 )
      So if it is commented out, is it enabled, or disabled?

      #ChallengeResponseAuthentication yes

      • Re:Workaround here: (Score:2, Informative)

        by lunenburg ( 37393 )
        That would indicate that the default is "yes", so if you want to disable it, you need to uncomment it and set ChallengeResponseAuthentication to "no". Then restart sshd.

        • Re:Workaround here: (Score:3, Informative)

          by codewolf ( 239827 )
          Actually, it is safe to make the ChallengeResponseAuthentication no change and restart, until you upgrade. But, you can not assume your version is vulnerable solely from the config file, it's a compile time option that makes it vulnerable, and this is different on many systems, so be safe, do the workaround until you upgrade.

    • Re:Workaround here: (Score:3, Informative)

      by Squeezer ( 132342 )
      It will take whatever the default is that is programmed into the code, which is prolly yes. So in other words if its commented out its more then likely enabled. So uncomment it and change it to no.

      I think I should start an OpenSSH remote root exploit of the month club.
    • In my /etc/ssh/sshd_config:

      # Change to no to disable s/key passwords
      #ChallengeResponseAuthentication yes

      This was on my Red Hat Linux 7.1 workstation (also acts like a private server only to me). Do I assume this is at no value right now and I don't need to worry?

      Thank you in advance. :)

    • CERT Advisory. (Score:3, Informative)

      by hearingaid ( 216439 )
      There's a full CERT advisory [cert.org] on the OpenSSH bug and the implications for your particular platform. Sysadmins, read it. Of course, you prolly all got it in your email like me, right? :)

      ftp.openssh.org is getting hammered right now... sigh.

  • Why was it kept hush hush? (Score:2, Interesting)

    by wub ( 69839 )
    Does anyone know why it was kept so hush? It's so unlike the open source community to not just put it all right out there.
    • The details of the bug weren't disclosed immediately because there was no patch available. Now that it can be patched, most system will be protected from the script-kiddie storm. But, as usual, there are plenty of lazy and/or ignorant sysadmins who won't patch this.
      It was hinted on bugtraq a while ago that a remote root exploit for SSH was discovered but would only be disclosed once patches were available.
      • The OpenSSH guys are guilty of the worst kind of underhanded dealing in this matter. As a vendor, I'm frankly, disgusted in every sense of the word. They deliberately compromised the security of other vendors through their actions by:

        * posting a workaround that broke functionality but didn't fix the problem,

        * failing to disclose (in advance) a workaround that does close the hole,

        * failing to release the source code to vendors before detailing the vulerability to the general public,

        * deliberately releasing the vulnerability five days earlier than expected, catching vendors off-guard, and

        * using strong-arm scare tactics to force a very broken feature on the end-user community.

        In short, they have made a mockery of reasonable procedure for security updates.

        If this is what we should expect from OpenSSH when future security vulnerabilities arise, then I, for one, will be investigating alternatives to OpenSSH, and I strongly encourage other vendors to do the same. The security of our users' systems is too precious to be left in the hands of someone who does not have their best interests in mind.
        • I use stunnel and telnet (plus mandatory ssl certs - so even though telnetd might have a bug, you can't exploit it without a valid cert).

          Years ago I took a look at ssh and thought it would have lots of problems (kludgy, lots of complex features stuffed into one binary). The "Sendmail" of remote admin.

          The past years have vindicated my decision many times over.

          Sure stunnel and openssl have had some problems too, but as long as the stunnel people don't try to stuff tons of features in, it'll still be much better than ssh securitywise.

          You could try vnc over stunnel if you really need GUIs.

          Cheerio,
          Link.

        • Re:Why was it kept hush hush? (Score:4, Insightful)

          by epine ( 68316 ) on Wednesday June 26, 2002 @01:21PM (#3770988)

          Every choice in handling this matter carries a different consequence for different groups of people. Theo can't serve every group equally.

          As it turns out, recent OpenBSD installations were exposed to this, where many other platforms were not exposed.

          The first question Theo had to decide was whether to spread the information around before his own user community was protected. Of course every vendor thinks they are entitled to this information. No black hats here! No rooted systems here! Your secrets are safe with us. Tell enough vendors, your secret is certain to escape.

          The next question to decide is whether to create a window of opportunity for his own user base to protect themselves before giving away anything of use to the black hat community.

          He can't do this without admitting that there is a big problem here. But any further details he gives become clues for those who might try to discover the flaw themselves.

          As it stood, he had an option to put forward which allowed his user base to protect themselves while giving nothing away to his black hat adversaries. privsep is a case of Doing The Right Thing. I'm sure Theo does get frustrated that vendors don't put a higher priority on Do The Right Thing initiatives.

          On OpenBSD itself, privsep has been there quite a while and I don't think it would be considered untested in its nascient environment.

          He couldn't very well suggest to his user base "disable challenge/response". That's like backing away from Mike Tyson.

          What could he have done differently?

          He could have informed his own user base to install the reasonably well tested privsep version *in advance* of informing other vendors of the actual problem in secrecy *after* he completed the actual bug fix patch. This would have meant keeping the patch secret for another week or two.

          But instead he chose to put his boot up the ass of vendors who think that compatibility with PAM is more important than adopting a model which eliminates 90% of the future prospect for more of the same.

          If Theo were entirely sane he wouldn't be doing what he's doing. Maybe he has your best interests at heart, but the same best interests you chose for yourself.

          There are always people who have good reasons for delaying The Right Thing. In the long term, I think these people contribute more to the sorry state of security that brash actions by people like Theo.

          If you invest your faith in Doing The Right Thing on the technical merits, I think you'll stick with OpenSSH. If you prefer the relationship model of working hand in hand behind the scenes, maybe you won't.
    • I could be that ISS does not want another PR fiasco like the one that it got when it released the Apache [slashdot.org] advisory recently

    • Re:Why was it kept hush hush? (Score:5, Informative)

      by kevinank ( 87560 ) on Wednesday June 26, 2002 @12:15PM (#3770489) Homepage
      The rationale not exposing the exploit was that if the exploit became known then immediately there would be many thousands of machines that could be exploited. That would be bad, so the question became 'is there some way to disable the problem code without fixing the bug', then a bug fix can be delivered after without anyone getting hacked.

      There were basically two ways to fix your configuration. One was simple, and actually the default on most systems. The other is a pain in the ass, but Theo likes the second method because it is aesthetically more pure; a better implementation of a security conscious application.

      The distributions (who couldn't get any information about the nature of the bug, just the suggestion that they fix the pain in the ass way of using sshd) correctly figured that they were being railroaded and balked.

      For what it is worth, privelege separation is a better architecture for a security concious program, but setting up a chroot jail and adding new users, along with the brokeness of several ports of the new privsep code especially in the area of pluggable authentication modules (ie: RedHat) means that although I now have 3.4p1 iunstalled on my boxen, I also have privsep turned off. Less pure, but I'm a pragmatist, not an idealist.

      • "The distributions (who couldn't get any information about the nature of the bug, just the suggestion that they fix the pain in the ass way of using sshd) correctly figured that they were being railroaded and balked. "

        The Debian security team just about killed themselves getting the upgrade out for all eleven architectures and patching and backporting it to Potato.

        And now we find out that we were never vulnerable.
        I think there will be a movement to put a price on Theo's head.
        • And now we find out that we were never vulnerable. I think there will be a movement to put a price on Theo's head.

          Before getting too upset with Theo, you should at least consider that security is Theo's life blood. The way he sees it, the primary bug in earlier versions of OpenSSH was the security architecture; by fixing that bug Debian is far ahead of the crowd since you will be impervious to a whole class of programming errors, of which this particular error is only a specific example.

          He certainly didn't believe he was giving bad advice, and the fact that this whole thing has backfired on him will probably be setback enough. I'd certainly hate to see him burned so badly that he decides to drop out, just educated that even rational, well educated people don't always come to the same conclusions given the same data, and that he must let others come to their conclusions on their own.

          For what it is worth I do admire the work the Debian team has done to get the new release integrated. I think it speaks volumes that the open team is also the only Linux distribution to have integrated the new features before the patch was released.

    • The last couple of weeks has demonstrated precisley what is wrong, from an end-user standpoint, with 'responsible disclosure' (yeuch!)

      I don't know why, but ISS seemed to get under the skin of a lot of security researchers with their release of details of the recent Apache problem. This release was *directly responsible* for someone (I forget who, but thanks are due) to code a fairly simple work-around in the form of an Apache module, so that people can quickly install some protection whilst waiting for a fix to appear, and ancilliary apache addons (modssl, php etc.) to catch up with the new Apache release, so we are now maore-or-less protected whilst compiling, testing and installing new versiona of about half a dozen bits of software. Because of this release, the problem can be handled in a calm and non-disruptive manner.
      Oh, and someone reported being hit with similar symptoms to this problem, well before ISS released the details.

      Take that in contrast to when this OpenSSH problem hit the net. I was well aware of OpenSSH 3.3 and the new security features, and had a plan to wait till the next release (to check for implementation problems) and then upgrade all our servers in an orderly manner.
      However,this morning, I opened Bugtraq to find a load of peeps that should know better (i.e. OpenSSH developers) screaming that there was a major root-exploit in the code I was currently running, that I had to upgrade immidiately, and no, they won't tell me what the problem is. Based on the available information, I made a judgement call, and suspended all incoming ssh access at the firewall until I could upgrade. As you can imagine, this pissed off a lot of customers. I also had to then reschedule my day to get, test and install this new version of SSH - I did not have time to put it through our usual QA process - to get us operational again.

      To add insult to injury, when the details were released, it turns out to be a problem with a feature we do not even use and a simple config change was a suitable work-around.

      Who do I get to bill for our (useless) 3 hour downtime?

  • Was there ever a working 'sploit? (Score:4, Interesting)

    by toupsie ( 88295 ) on Wednesday June 26, 2002 @11:10AM (#3769974) Homepage
    I have read much about this problem in OpenSSH and fearing the worst...checking logs to see how often my SSH version was scanned. However, as far as I know, I haven't had any break ins using a SSH exploit. Thank God for TCP Wrappers, at least that helps when you find out about these things.

    Did any one of the many black hat groups out there actually work up a exploit or was this caught in time that it was just a possibility of being exploited?

    • I have it on good authority from a collegue of mine (okay, fine, he's a script kiddie, but he keeps up on all the '0day' exploits, so he comes in hanndy) that not only is there an exploit for OpenSSH, but there is one for the latest version of SSH.com's ssh server (3.2.0 IIRC).

      He's a rather reliable source. In fact, he let me know that Apache on essentially ANY platform was vulnerable, long before IIS or Bugtrack had that info. Interestingly enough, a few days later, one of our servers (not one that I admin-I NEVER run Apache as Root) was Root'ed. It was just a small workgroup server, no real harm done.

  • New Slogan! (Score:4, Funny)

    by skinney ( 395862 ) on Wednesday June 26, 2002 @11:10AM (#3769977) Homepage
    "One remote hole in the default install, in nearly 6 years!" you can see it here: OpenBSD [openbsd.org]

    ~Shane

    • Re:New Slogan! (Score:5, Insightful)

      by AndrewHowe ( 60826 ) on Wednesday June 26, 2002 @11:14AM (#3770012)
      It was suitably humble of them to admit it and update their homepage.
      Unfortunately, one remote hole is all you need. Such is the Unix nature.

    • And that is the difference between open source and proprietary. You can argue until the cows come home which one is better, but open source is demonstrably more honest. If there's a hole, you find out about it. It isn't hushed up and smushed into the next Service Pack, regardless of whether it's being sploited or not.

      I'm currently building a firewall machine for my brother. I'd considered openBSD, but was going to just stick to what I know and use a cut down Linux distro. But this changes my mind. I'm still old fashioned enough to respect honesty and integrity; people who display those virtues (I've found) tend to write better code, because they're more open to positive criticism and apply higher standards to their work. So openBSD it is, and roll on the next vulnerability, sometime in 2008.

    • It's better than the alternative:
      "5 hours without remote holes in the default install"
  • Whether the source is open or closed, you're going to have something slip through all those lines of code.

    The key here is that it is caught and corrected, and solutions offered.

  • I'm impressed (Score:3, Insightful)

    by bigberk ( 547360 ) <bigberk@users.pc9.org> on Wednesday June 26, 2002 @11:11AM (#3769987)

    I'm impressed that the OpenSSH team gave us advance warning that this bug was going to be announced, and also how to reduce the risk (privilege separation).

    From [openssh-unix-announce] Re: Upcoming OpenSSH vulnerability

    "There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week.


    However, I can say that when OpenSSH's sshd(8) is running with priv seperation, the bug cannot be exploited.
    . . .
    We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published)."

  • Is it just me.... (Score:2, Insightful)

    by GnomeKing ( 564248 )
    ...or does anyone else think that the way that this particular exploit was handled was, to say the least, irregular...

    Personally, I'd go as far to say that I would rather switch to an alternative SSHd in the period that we were given from the presence of the exploit being announced to the fix being released - rather than following the "everyone upgrade now to our super-duper-improved privaledged seperated version"

    It just seems to me that rather than attempting to help us users, the way that this bug was handled was just a huge PR stunt...

    and I dont like it
    • I'm not sure why people think this was handled badly.
      OpenSSH enjoys a broad user base and is on a lot of trusted systems, a lot of admins trust their jobs to it. Theo, Neils, Markus et al. have been pushing for people to upgrade to the later versions that contain support for Privilege Separation which make this hole pretty much worthless in the first place. However, as Theo stated on the Announce list people have been hesitant to upgrade to the newer version.
      ISS notified the OpenBSD/OpenSSH group of the security hole and just like every other exploit they find, they worked WITH the developers to give them a little time to develop/test the patch before they made the announcement. How is this different than anyone else?
      Theo also said OpenSSH and the exploit wouldn't be released until next Monday, but the fix has been released today. My guess is that they agreed to do the announcement as soon as the patch was developed or Monday, whichever was sooner. The patch was completed/tested ahead of schedule, so there you go.
      Congrats to ISS for discovering the flaw, they killed the five year streak.
      Congrats to the OpenBSD team for putting together such a good system and hopefully the next streak will be even longer.

      Now the hole has been disclosed, the patch has been released. Get off your arse and start patching or don't bitch when you get rooted.

    • ...or does anyone else think that the way that this particular exploit was handled was, to say the least, irregular...

      I agree totally. What is that dude Theo smoking? We've had remote root exploits before and they were handled properly. This one was like a forced push for untested brand new privsep code. No thanks. I just added "ChallengeRepsonseAuthentication no" in my config instead.

      To me it seemed like a PR stunt. Why it was handled this way I don't know, but I'm not going to jump when he demands everyone upgrade or else.

      I'd go as far as to say I want to see a working exploit for this. It sounds fishy. An integer overflow (not a string overflow) causing remote root? I find that very hard to believe.

      Pay no attention to the man behind the curtain...

    • I would rather switch to an alternative SSHd in the period that we were given from the presence of the exploit being announced to the fix being released

      You have found the big hole in the "window of opportunity" description of the danger of a bug (Bruce Schneier, Cryptograms and books). Fortunately, it gives even further support to the "full disclosure" movement.

      We don't need to wait for the bug-fix release to secure our systems. We can switch to alternate products, change config files, and even turn off convenient services that are not strictly necessary or block them at the firewall temporarily.

      Schneier says the window is open between discovery of the bug and the time when a fix is released (and longer until everyone fixes their systems). This is a perfect example of how full disclosure allows you to close the window even before a patch is developed.

  • Cheers, Theo (Score:5, Interesting)

    by gorf ( 182301 ) on Wednesday June 26, 2002 @11:15AM (#3770021)

    All that you need to do, as far aas I understand it, is turn Challenge/Response authentication off (which nobody uses anyway). So the line in /etc/ssh/sshd_config reads:

    ChallengeResponseAuthentication no

    and then restart the daemon.

    Big deal.

    I don't see any need to upgrade anything. Yes, privilege separation is nice in terms of future security, but I prefer the (more likely) known stability of software that has been in use for a while.

    Debian security policy is that vulnerability fixes are backported (to avoid adding anything that could cause instability or further insecurity); this was made impossible by Theo's and ISS' advisory which lacked any details about the exploit. This may have been justified had the exploit not be able to be prevented by a simple configuration change (in order to give administrators time to prepare an upgrade their systems), but not for this.

    Cheers, Theo, you just cried Wolf for the entire community. If there ever is a hole major enough that everyone should (or might want to) upgrade to a version which is by nature immune rather than give away the exploit by releasing a patch, noboby's going to believe you now, and probably not anyone else either.

    • Although it looks like Theo could have simply told everyone to disable challenge/response authentication, I'll venture to guess that he had a reason for not doing so. Consider that his original announcement was deliberately obscure, in order to avoid advertising the vulnerability to crackers, while vendors scrambled to patch their systems. If Theo had originally said "turn off challenge/response", all the crackers would immediately know where to look for the vulnerability, and the vendors would no longer have the head start they needed.

      Here it is a few days later, the vendors have been given time to implement fixes, and we have disclosure. What are you people complaining about? Apart from the lack of social grace that he's famous for, I'd say Theo handled this about as securely as he could. Moreover, he did so by folloing the procedure widely accepted in the security community. Am I missing something?
      • the vendors would no longer have the head start they needed

        Except the vendors didn't get a head start because the vulnerability wasn't disclosed to them either. They were just handed OpenSSH 3.3 and told, "Here. Use this. It doesn't fix the hole that we won't tell you about, but it will prevent it from being exploited." Now, today, the vendors have finally been allowed to see a patch and can start implementing fixes other than "upgrade to the newest version".

        Hmm... "There's a problem, we won't tell you what it is, but if you upgrade to the newest version, it will go away, plus you'll get nifty new features along with it!" Where have I heard that before?
        • Hmm... "There's a problem, we won't tell you what it is, but if you upgrade to the newest version, it will go away, plus you'll get nifty new features along with it!" Where have I heard that before?

          From every programmer ever? It's pretty standard when reporting a bug to get "please upgrade to the latest version and try again." Nobody wants to have to go back and fix bugs in every version of every program they've ever written.
          • From every programmer ever?

            Nope. I guess I just forgot that the Debian security team, which backports security fixes, is an anomaly.

            More seriously, though, one of the often-touted benefits of open source/free software is that we produce security patches which don't introduce hordes of new features (and bugs). It's sad to see good projects starting to behave like proprietary software vendors and doubly so that it would be something as respectable as openssh.
        • The difference here is:

          1) The problem was fixed in a couple of days

          2) The upgrade was free

          3) This is the first serious security hole OpenBSD has had in nearly 6 years.

          For extra credit, compute the following: average number of days between disclosure and fix, times the cost of the upgrade that gives it to you, times the number of remote-root-level security exploits in your average BorgOS over 6 years.

      • Apart from the lack of social grace that he's famous for, I'd say Theo handled this about as securely as he could.

        Yes, he did.

        Moreover, he did so by folloing the procedure widely accepted in the security community.

        No, I don't think he did. Normally the exploit is announced at the same time as the fix or workaround. Instead of this, he told everyone to upgrade (which is an unnecessary inconvenience for at least some people, who could just use the workaround). He has basically forced us to (unnecessarily) upgrade to a version which has known problems.

        I don't think this is standard practice, but clearly it isn't a standard situation (ssh is the one thing that locked-down boxes still may have open, and the upgrade conveniently stopped the exploit without giving it away). I'll admit that whether or not he did the right thing isn't clear cut, but I don't think he did.

        With every other exploit/fix that's announced there's a "Window of Exposure" during which you are vulnerable, and that was still the case here. The only difference is that there was a chance that fewer people knew about it. But given that the exploit was found, there's no reason that it hasn't already been actively exploited for a while by black-hats.

        It's generally accepted that there's always going to be a "Window of Exposure", and that the way to keep this to a minimum is to coordinate the announcement of the exploit with the announcement of the fix. I don't see why that couldn't have been the case here.

        While I accept the advantages of his approach, in my particular case the disadvantages far outweigh them (if I had decided to upgrade all the boxes I'm responsible for, this would have taken me maybe about 36 hours and many remote reboots. Had I messed up then entire businesses would have gone without functional computers). My problem is that he made the decision for us, and this is exactly what full disclosure is not supposed to do.

      • Except in this case the vendors, such as Debian, didn't have any head start. As per the above post [slashdot.org] Theo didn't tell the vendors anything either.

    • Re:Cheers, Theo (Score:3, Informative)

      by Matts ( 1628 )
      You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

      No thanks, I'll upgrade my servers and enable priviledge separation. We may or may not see exploits that get around turning off the ChallengeResponseAuthentication bugs, but I'm not taking that chance.

      • Re:Cheers, Theo (Score:3, Informative)

        by platypus ( 18156 )
        You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

        Minor correction (only AFAIK, please correct me if I'm wrong):
        ISS told us that the bug was not exploitable on any 32bit plattform, later we found out that this bug is exploitable on 32bit BSDs (free* and open* IIRC).
        It's not exploitable on x86 linux.
      • I imagine he's probably trusting the OpenSSH team who have finally admitted that this simple workaround works just fine.

        The dire warnings suggesting upgrades to 3.3 were, as far as I can tell, just a strawman to get vendor assistance in actually getting 3.3 to work. Although priviledge separation isn't a bad idea in principle, I'd question its value when you're still left with 2500 of recently-written, can't-possibly-have-been-thoroughly-audited code in the priviledged half after the 'upgrade'.

    • Re:Cheers, Theo (Score:5, Insightful)

      by transient ( 232842 ) on Wednesday June 26, 2002 @11:59AM (#3770380)
      This is a problem throughout most of the security community, and it's the reason I don't subscribe to bugtraq anymore. At the risk of starting a flamewar, my impression of people who are really into security as a group is that they have an over-inflated sense of their own importance. Every seminar I attend, every publication I read, and every security expert I speak to tells me the same thing: that hordes of hackers (and now terrorists, too) are out to melt my hard drives and make me lose $1 million a minute.

      This is simply not true. I believe that security is important, and that there are certain measures sysadmins should take in order to keep undesirables out of their systems. But every time somebody finds some tiny little problem in a program, suddenly the world screeches to a halt, everyone panics, and we get bombarded with headlines and emails demanding that we upgrade immediately or our data centers will explode. Oh, and by the way, don't forget to put two pages of credits on the exploit's "whitepaper".

      The result of all this horn-tooting is that I don't care anymore. Whenever someone utters the words "security advisory" I simply stop listening, because 99% of advisories are crap.

      • Hold on a minute...

        There's nothing to say that this isn't a vulnerability in ssh, nor that is isn't exploitable. I'm complaining about the way it was handled, not the fact that it doesn't exist!

        I have seen few "crap" advisories. Most bugtraq postings refer to real vulnerabilities, and the ones that don't are quickly pointed out.

        It is important to keep up; the results from those who didn't are well known.

        ...because 99% of advisories are crap

        Then at the very least listen to (hopefully digitally signed) advisories from your own vendor.

  • well... (Score:2, Informative)

    by ChrisMG999 ( 308536 )
    Well at least they are honest about it, and are trying to fix it. There's a company out here in redmond that could take lessons in honesty and security from them.
  • And of course, I just installed OpenSSH from HP last week, on about 40 machines..

    Thank goodness for closed networks!

  • What is ChallengeResponseAuthentication? (Score:5, Interesting)

    by rherbert ( 565206 ) <slashdot@org.ryan@xar@us> on Wednesday June 26, 2002 @11:21AM (#3770071) Homepage
    How does this authentication method work? I just disabled it, and I was still able to log in using my RSA keys and password authentication (which are the only methods I use). The documentation says it's for s/key authentication, but what is that? How common is this authentication method, and who would use it?

  • Easy workaround (Score:5, Funny)

    by garett_spencley ( 193892 ) on Wednesday June 26, 2002 @11:24AM (#3770085) Journal
    Don't use SSH. Switch to telnet instead....

    ChallengeResponse... oh please! Telnet's never had these problems.

    (note for the humour impared: this is a *joke*).

    --
    Garett

    • telnet+SSL+certs (Score:3, Interesting)

      by TheLink ( 130905 )
      if you don't need all the features of SSH, try telnet+SSL+certs

      It's likely to be safer.

      I've been using stunnel+telnet for years and I have had to patch/upgrade a lot fewer times than people using SSH.

      Cheerio,
      Link.
    • ChallengeResponse... oh please! Telnet's never had these problems.

      I know you were trying to be humorous, but keep in mind that telnet *does* support challenge-response via the pam system under Linux and most modern systems.

  • okay, let me get this straight. (Score:5, Interesting)

    by Dr. Awktagon ( 233360 ) on Wednesday June 26, 2002 @11:28AM (#3770121) Homepage

    Okay, busy morning but glancing at the news, here's what I see:

    There was a bug in the challenge/response code between 3.0-3.2.3. In fact, it's an "overflow" according the advisory. This means to me, it should be a fairly easy fix. Quote:

    It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise.

    In addition, this overflow only works when SKEY and/or BSD_AUTH is enabled. But this seems to be "not enabled...in many distributions". How about Linux? However, OpenBSD has BSD_AUTH enabled (natch). Quote:

    At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled. The SKEY and BSD_AUTH options are not enabled by default in many distributions.

    And now to add insult to injury, the 3.3 I installed yesterday has a new different buffer overflow, so I have to jump to 3.4 now (does it have any new bugs too?)

    I don't like to jump versions on production machines. I like to fix what's running for minimum disturbance.

    Can someone please explain why this vulnerability was handled this way? Why wasn't there a maintainance release that just fixed the @#$@#% problem?

    I know: since the bug affected so many people, Theo thought it would be better to bury the problem in his privsep code, instead of fixing it and letting the blackhats run "diff" and find it for an easy 0-day-'sploit. In other words, security by obscurity, just like the big guys. That stinks, if you ask me.

    On the other hand, I charge by the hour when I upgrade my client's machines. So thanks Theo! $-)

    • ha ha.. it looks like many of my machines already had "ChallengeResponseAuthentication no" for at least the last few months. I'm going to go beat myself in the head with a brick now.

      • ha ha.. it looks like many of my machines already had "ChallengeResponseAuthentication no" for at least the last few months. I'm going to go beat myself in the head with a brick now.

        You need to get a girlfriend. Then *she* can smack you w/ a brick. Seriously, my gf recently started to carry a brick in her purse. Now if I get out of line she just tosses it from hand to hand & I straighten up real quick :)

    • no it's not because he was afraid some black hat
      could run diff.

      it's because the vendors wouldn't cooperate to
      make the privsep work and he got all frustrated
      because the other code couldn't be fixed in time
      either.

  • MacOSX update ? (Score:2, Interesting)

    by selderrr ( 523988 )
    I wonder is Apple is going to release a minor OSX update for this. If they do, they prove themselves worthy supporters of OpenSource and creators of an OS that truly respects security.
    If they don't, welll, they're still a 100 times more secure than 95% of the market

  • For gods sake (Score:5, Insightful)

    by Mr_Silver ( 213637 ) on Wednesday June 26, 2002 @11:33AM (#3770161)
    Never have I seen such a pathetic display of whinging. Bug was found, 3 choices:

    1. Tell you lot nothing, get the fix done and released (in which case you wouldn't have known about it until the fix came out).

    2. Or tell you there is a bug, you can fix it temporarily by doing this until we get the fix out. In which case you decide either to follow him or do nothing (because after all, thats what you'd have been doing if nothing was said)

    3. Or say, we have a bug, it's this and this and this is how you exploit it and then you lot all either scramble to install something else or sit around praying you don't get rooted whilst they compose a fix because now everyone and their dog know exactly how to exploit it.

    Geeesh, be thankful he actually told you number 1. Next time, I think he should probably stick with number 2 and just tell you when the fix is out - at least then you can't whinge about it.

    • Geeesh, be thankful he actually told you number 1. Next time, I think he should probably stick with number 2 and just tell you when the fix is out - at least then you can't whinge about it.

      I agree. 1 is better than 3, but 2 is what he has been doing for a long long time. This was a stunt to try and make everyone upgrade to 3.4 with the nifty privsep code that isn't fully working on all platforms yet. I suppose he's running out of alpha/beta testers and needed more or something.

    • Re:For gods sake (Score:2, Insightful)

      by DustMagnet ( 453493 )
      Sure, given your choices that's best, but they could also:

      A. Tell me that it only effects a small portion of installed systems.

      Geesh, why make it sound like everyone had this problem?

  • Where are vendor statements that usually accompany such announcements?

    Thankfully the default setup on SuSE 7.3 is "ChallengeResponseAuthentication no". Unfortunately, the default on Redhat 7.[0123] is "ChallengeResponseAuthentication yes".

  • The good news ... (Score:3, Insightful)

    by joe_fish ( 6037 ) on Wednesday June 26, 2002 @11:47AM (#3770254) Homepage Journal
    ... is that on the 2 RedHat 7.3 boxen I have access to already have "ChallengeResponseAuthentication no" - so I guess this means I'm not vulnerable?

    Assuming this is true for all RH7.3 boxen, there aren't hundreds of boxes waiting to be r00ted. It sounds from the comments like Debian is vulnerable - what about older RedHats, and other distros?

    I get the feeling this was is a molehill made into a mountain.

  • How to fix ... (Score:5, Funny)

    by joe_fish ( 6037 ) on Wednesday June 26, 2002 @11:54AM (#3770331) Homepage Journal
    Just add a line to your /etc/ssh/sshd_config like this:

    CheckPasswords false

    And then reboot your sshd.

    Finally mail me, and I'll check that you really are safe. Oh and don't about slashdot users giving you bad advice you can be sure to only get accurate information here.

  • I like the new slogan... (Score:3, Insightful)

    by bluebomber ( 155733 ) on Wednesday June 26, 2002 @11:55AM (#3770337) Homepage
    the openbsd website has been updated:

    One remote hole in the default install, in nearly 6 years!

    *sigh*

    Fun while it lasted, I guess...

  • Affects who? (Score:4, Interesting)

    by MSG ( 12810 ) on Wednesday June 26, 2002 @12:00PM (#3770384)
    So, what do we know about who is affected? Immediately after reading the announcement, I checked Red Hat Linux's build of OpenSSH. The configure script positively reports that the affected authentication mechanisms are not available. 'ssh -v' does not indicate that challenge-response authentication methods are available either. I imagine that other Linux distros are similar?

    RHL configure output:
    OpenSSH has been configured with the following options:
    ...
    Smartcard support: no
    S/KEY support: no
    BSD Auth support: no

  • Code Audits, the UNIX security model (Score:3, Interesting)

    by Nerant ( 71826 ) on Wednesday June 26, 2002 @12:09PM (#3770452)
    How secure any software you're running on your system(s) depends on the quality of the code audit done on the code. I'm not judging the standard of the OpenSSH's team code audit here: things will slip through given the inherent complexity of software.
    Privilege separation is a step in the right direction. By minimising the amount of code running as root, it makes code audits simpler and more through, and minimises the damage any potential exploit could do in the part running as a normal user.
    Stepping back from the situation, privilege separation is just a bandaid for the lousy UNIX security model. Yes, granted, UNIX / Linux (i have no experience with other UNIX systems, so i shall reserve comment) have a security model that's used, as compared to Windows 9X. (Windows 2K has a security model, but the MS culture makes it difficult to administer it, but i digress). However, this security model is too coarse grained: it grants "root" too many privileges, too many rights. This is evident in the move towards ACLs, for example in NSA's SE Linux, as well as LIDS.
    We need to overhaul the security model to one that's not prone to insecure software as much. Note I said as much:No system is 100% secure, and I don't want to replace my system with a toaster.
    Appreciate feedback. Thanks. =)
    • suggest you go have a look at LSM [immunix.org] - Linux Security Module ... see the .mp3 of the lsm presentation at this weeks kernel summit at lsm discussion [sourceforge.net]. LSM creates hooks in the kernel functions which are security relevant (about 150) and can mitigate access to a couple dozen kenel data structures.

      security model is too coarse grained: ... move towards ACLs, for example in NSA's SE Linux, as well as LIDS

      Actually SELinux does not implement ACL's, but rather Type Enforcement. It also has potential (and experimental impementation) to implement MLS or other security policies / methods.

      What type enforcement gets you is the ability to create highly fine-grained security controls, so that the program and user-security-context have privilege to execute critical functions and that privilege can be removed from the root user.

      One of the debian SELinux implementers placed an SELinux system on the 'net with root-password / ssh access advertised. This is not a proof of safety, but in fact noone succeeded in escalating privilege.

      As it looks like LSM is on track to be in kernel 2.6, at least the way is presently paved.

  • Is there a page anywhere that summarizes the holes/bugs/exploits in OpenSSH discovered in the last, say, two years? year? six months?

  • The 3.3 release of OpenSSH required that with PrivilegeSeparation turned on, Compression had to be turned off for Linux kernels in the 2.2 line. Does anyone know if this is true for the 3.4 release as well, or has that been fixed?
  • I discovered after downloading and building 3.4p1 on my Solaris 7 box that Solaris doesn't support a shared memory feature 3.4's privilege separation uses. As a result, you can enable privilege separation or compression, but not both at the same time. Just something to be aware of if you're considering an upgrade. (It's possible more recent versions of Solaris don't have this problem.)

  • How soon until djbssh? (Score:4, Interesting)

    by GregGardner ( 66423 ) on Wednesday June 26, 2002 @01:19PM (#3770970) Homepage
    I can't wait until djb decides to write his own ssh. You can say what you want about djb and his personality, but he does know how to write some secure software. Sure, it's not the easiest thing to install and you have to create a boatload of users, but privilege separation has been in qmail since 1.0.0. Theo is getting around to it in v3.3? Never heard of any root compromises from qmail or djbdns. So hopefully this latest hole in OpenSSH has annoyed djb to the point of rolling his own.

  • Fuck it. (Score:2, Funny)

    by xmutex ( 191032 )
    I'm going back to telnetd and blind optimism.

  • This all could have been avoided... (Score:3, Informative)

    by chrsbrwn ( 14235 ) <.chrsbrwn. .at. .gmail.com.> on Wednesday June 26, 2002 @02:57PM (#3771707)

    Meaning this brouhaha, of course...

    Just to combat some of the misinformation that has been spreading around here:

    • privsep is not a "new" feature... it has been available since OpenSSH 3.1p was released, almost 2 months ago. In that two months none of the various vendors and users who are whinging now appear to have bothered to help the openssh team test the privsep code and develop patches to make it work better.
    • With privsep enabled, this hole, and any future root hole are made much more difficult, sometimes even impossible, to exploit. Privilege separation is just the right way to code network daemons -- postfix does it, apache does it, courier imap does it, qmail does it -- and now, openssh does it. It is a bit more complicated for openssh to do it because it needs to interface directly with some operating system facilities like authentication, PAM, etc that require root privileges.
    • I installed 3.3p yesterday on all of my network facing systems, and will be upgrading to 3.4 as soon as Debian has it available -- I firmly believe in the concept of privilege separation, and will always seek out network daemons that use it.
    • I thank the Debian team, OpenBSD/OpenSSH teams, Wietse Venema and the rest of the Postfix hackers, the mailman team, the GNU project, all the Linux kernel hackers, and anybody else who has contributed free software that I rely on to do my job for making my job as a sysadmin smoother than it might otherwise be. I know the alternative, because I am also responsible for an Exchange server, and I spend far more time patching that and making sure it is up to date than I do with any of my Debian servers.

    Don't complain too much folks... you could have to do without a robust free ssh implementation.

  • What is wrong with this picture (Score:3, Interesting)

    by nelsonb ( 588475 ) on Wednesday June 26, 2002 @03:17PM (#3771938)
    What the hell is wrong with the people at ISS? This is the second "incident" in as many weeks. The message from the Theo at OpenSSH and other Linux Vendors said the info AND the realfix would be released early next week. This certainly seemed like a very responsible method of alerting people. Give everyone a week to upgrade to 3.3 and enable an option that could help mitigate any potential damage and then release a fixed version of the program and the full details. This gives large production houses enough time to get the new version/config through change control and even gives admins who don't read bugtraq lists time enough to hear about throughanother channel. Everything was working out pretty well and ISS has to go and screw up a pretty good plan.
    Does ISS have a problem with queued up advisories and techs with itchy trigger fingers? Does Time some how run differently in Atlanta? I guess another lame self-justification will be forthcoming from ISS, but there is no excuse for this. What about the little people? Were you in such a hurry to get your X-Press Update advertisement out that you don't even consider the ultimate end-user? Is it so easy to forget that not everyone is in organizations that discover or releases 0-day info amongst themselves? Most administrators don't read bugtraq, and those thatdo received a polite, clear note from Theo:

    Monday, June 24, 2002 11:22 PM

    There is an upcoming OpenSSH vulnerability that we're working on with ISS.
    Details will be published early next week.
    ....etc etc etc

    Now ISS has up'd the ante and released it justa day and a half later. 1 and 1/2 days isn't a lot to verify that a production environment will not be adversely effected byANY new/changed element. So it would seem that "working with ISS on this issue"is synonymous"we are waiting to get blindsided". This also leads into another interesting issue. Why did ISS's reckless announcement take minutes to get through bugtraq and the OpenSSH's initial, responsible warning take 24+ hours to process? I can plainly see that Theo's letter was sent on Monday but for some reason only gets here today. I know that SMTP mail is slow..but I don't thinkmy server isTHAT slow. Fortunately, it showed up on the vuln-watch list as well and we were able to help spread the word.

    > X-Force is aware of active exploit development forthis vulnerability.

    I don't know if I really even believe you on this certainlyyour recent actions are not that of a company that seeks to garner trust. Of course the minute anyone suggests there is a problem with product XYZ, thousands of bored people are going to start poking around "actively" trying to develop an exploit! But blind testing from scratch would certainly have taken longer than the proposed "quiet week" before publishing details.So, lets suppose it was a more informed testing. So who knew enough about this to let it out? ISS and the OpenSSH dev team. One is made up of hard working developers who love aprogram enough give their time away to make a really great product. The other is composed of people who routinely socialize with the underground "active exploit development" community. In my opinion, at least one side would have absolutelyno motive leak their information. So I propose: A: Your analysis of the exploit development process was faulty B: there was no active development for an exploit, and you released the info for your own good.C. Someone's teamis leaking information.

    In any event, there no need for any furtherunderground exploit "R&D"; everyone now has the diff blueprints to get directly to the end goal. Granted, there are people out there intelligent enough totake the time find the issue and to code an exploit without this knowledge. But these type of people wouldn't likely release it to the general populace, instead it would be used for select targets. Targets that would most likely already have security teams in placeand be up on warnings and patches. Instead we have a patch diffs in the hands of everybody and now lower skilled programmers can code the exploit. These people will spread the exploit far and wide simply for fame; only this time the targets will be everyone.

    No one wins with this route you have chosen ISS. You and your X-force team used to be a respected group in my book. In the past they have provided valuable information to the security community and helped companies across the world to better secure themselves, but the handling of this and the Apache vulnerabilities are shining examples of how NOT to do things. So much for ISS being a "Trusted" center of knowledge. Trust and honor are coins you can only spend once.

    Nelson Bunker, CISSP
    VP of Security
    Critical Watch
    The opinions expressed in this advisory and program are my own and not of any company.
    The big print giveth, the little print taketh away

    • Actually, I know what's wrong. Theo's notice was basically "There's a hole, wait until we release a new version and then do a major version upgrade in a hurry.". ISS's notice was "Here's the hole, here's the way to close it in your existing software.". I'd rather Theo have told everybody the simple way to close the hole right off, rather than leaving everyone hanging.

Slashdot Top Deals

"Imitation is the sincerest form of television." -- The New Mighty Mouse

Close