Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Encryption Networking Software IT Linux

Flaw Made Public In OpenSSH Encryption 231

Posted by timothy from the days-to-whom dept.
alimo20 writes "Researchers at the Royal Holloway, University of London have discovered a flaw in Version 4.7 of OpenSSH on Debian/GNU Linux. According to ISG lead professor Kenny Patterson, an attacker has a 2^{-18} (that is, one in 262,144) chance of success. Patterson tells that this is more significant than past discoveries because 'This is a design flaw in OpenSSH. The other vulnerabilities have been more about coding errors.' The vulnerability is possible by a man-in-the-middle intercepting blocks of encrypted material as it passes. The attacker then re-transmits the data back to the server and counts the number of bytes before the server to throws error messages and disconnects the attacker. Using this information, the attacker can work backwards to figure out the first 4 bytes of data before encryption. 'The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH, said Patterson. ... Patterson said that he did not believe this flaw had been exploited in the wild, and that to deduce a message of appreciable length could take days.'"
This discussion has been archived. No new comments can be posted.

Flaw Made Public In OpenSSH Encryption More

Flaw Made Public In OpenSSH Encryption

Comments Filter:

  • Old version = old news (Score:5, Informative)

    by Anonymous Coward on Thursday May 21, 2009 @01:47PM (#28043689)

    OpenSSH 5.2 was released in February already which has builtin countermeasures against this form of "attack." Next.

    • Re: (Score:3, Informative)

      by Thornburg ( 264444 )

      I agree. I just checked all the machines I have immediate access to, and they are all on 5.1. Why does a vulnrability in 4.7 matter?

    • Re:Old version = old news (Score:5, Insightful)

      by againjj ( 1132651 ) on Thursday May 21, 2009 @02:09PM (#28044129)
      The interesting part here is that more details have been released about what the flaw actually was. Before, it was merely "there is a flaw, and we have notified vendors", but now more details are available. In particular, that while 5.2 has countermeasures, it is a flaw in the protocol itself, and not the implementation. "Countermeasure" does not equal "completely solved".

      • Re: (Score:3, Interesting)

        by kasperd ( 592156 )

        The interesting part here is that more details have been released about what the flaw actually was.

        But where did those details get released? They are not on the zdnet article in the link. Based on the vague description, I have a guess about what the problem probably is. You take cipher block you want to get decrypted and send it in the position in the stream where the length of a message would be. The server then decrypts it and finds the length. If the length is a 32 bit field but only lengths up to 2^14 a

    • The attacker then re-transmits the data back to the server and counts the number of bytes before the server to throws error messages and disconnects the attacker.

      This seems easily fixable. Have the server wait a random amount of time (say between 1 and 5 seconds) before throwing an error and disconnecting. During the "wait" period the server would continue to accept data and simply pipe it to /dev/null.

      Patterson said that he did not believe this flaw had been exploited in the wild, and that to deduce a m

      • This seems easily fixable. Have the server wait a random amount of time (say between 1 and 5 seconds) before throwing an error and disconnecting. During the "wait" period the server would continue to accept data and simply pipe it to /dev/null.

        Then you wait five seconds between each byte you send. You could also say the server should accept a random number of bytes before giving the error, but that's still only going to slow an attacker down. Just keep submitting the same string over and over, and if you know the distribution of the number of extra bytes accepted, you can figure out to arbitrarily high probability which byte was really responsible for the error. Just check the average byte number rejected after a hundred tries, say, and then s

    • Re:Old version = old news (Score:5, Insightful)

      by dave562 ( 969951 ) on Thursday May 21, 2009 @02:44PM (#28044705) Journal

      It may be the "old" version, but it is the version most readily available. I setup an Ubuntu server (9.04) a couple of months ago. I used apt to get OpenSSH on it last month. The version it retrieved is

      OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007

      Just because a new version is out doesn't mean people are using it. People who rely on package maintainers or "the community" to help them out and keep things up to date could very well be let down. Moral of the story, if you want something done right, you have to do it yourself.

      • Re:Old version = old news (Score:4, Insightful)

        by sirsnork ( 530512 ) on Thursday May 21, 2009 @02:57PM (#28044889)

        Why? Given the now public nature of this and the fact that there are countermeasures how long do you think it will be until an updated package is available for Debian and all it's children projects?

        I'm guessing a few days to a week before these countermeasures are patched into Debian's version. The whole point of ditributions is because keeping every piece of software up to date manually on even a single linux box is an arduous task at best.

      • Meanwhile, I was pleasantly surprised to see Mac OS X on 5.1p1. Now that could have dropped this past week with 10.5.7, but it's nice to know that even vendors with perhaps less of a stake in most-current packages are keeping up to date.

        Whoever that guy was earlier with 3.9, well o_O indeed.

    • I wish people would try to understand CRYPTO hacks (Score:5, Interesting)

      by omb ( 759389 ) on Thursday May 21, 2009 @03:49PM (#28045549)
      This was never a real threat, just another piece of Academic FUD. To be vulnerable as an interactive ssh user you would have to ignore 100,000 aborted sessions to expose 14 bits of plaintext, I think I would notice, and block the attacker.

      There are a whole suite of cyphers, including AES aka Rijhndael are configurable, have you done yours?, and not vulnerable.

      Finally the protocol is trivially fixed.

      Now I for one, whilst I have the highest respect for the work done by people like Ross Anderson and Schnieer am fed up to the back teeth with alarmism from governments, NGOs and academics -- all of which add up to give us more money.

      If you dont know these researchers were working for the UK equivalent of Homeland Security and failed to inform SSH of the details of the attack, doubtless quoting National Security.

      These people who parade nonsense should be tarred an feathered and sent on the next rail.

      • To be vulnerable as an interactive ssh user you would have to ignore 100,000 aborted sessions to expose 14 bits of plaintext, I think I would notice, and block the attacker.

        What you say is true.

        However, who says SSH has to be interactive? What about rsync backups over SSH? Automated connections that use SSH? Basically, anything and everything is tunnelled through SSH, so this is huge. If the attacker has time and you have a network of, say, 100 machines that initiate 1000 SSH sessions a day, you could h

        • I assume the parent failed every numerate course he ever took, and never took any kind of statistics for idiots course, and has not bothered to read and understand the attack.

          An continues to spread FUD.

          The attack requires a Man in the Middle scenario, if I ssh into a random machine the MiM is __VERY__ unlikely to work unless the NSA and my ISP are in cahoots and I dont notice that connection takes a nonsensically longer time (15min v 3s), ... then I have to tolerate 100000 failures/connection.

          Now comes the

  • Good Thing (Score:5, Funny)

    by neoform ( 551705 ) <djneoform@gmail.com> on Thursday May 21, 2009 @01:47PM (#28043691) Homepage

    Whew. Glad I use Telnet.

    • Re:Good Thing (Score:5, Funny)

      by timeOday ( 582209 ) on Thursday May 21, 2009 @04:06PM (#28045759)

      But telnet transmits your credentials unencrypted! To be super-secure I simply avoid transmitting them in the first place...

      root@host# nc -l -p 1999 -c bash

      user@otherhost: nc otherhost 1999
      whoami
      rm -fR /

      (PS don't actually do this)

    • Re:Good Thing (Score:5, Informative)

      by mzs ( 595629 ) on Thursday May 21, 2009 @04:47PM (#28046289)

      It may sound funny, but the MIT Kerberos sources contain an version of telnet and telnetd that support encryption. There has not been a vulnerablity in that for a while that I know of. There was a stupid vulnerability in logind on Solaris though which that telnet used. Also there is an encrypted version of rsh, rshd, and klogind in that source code. That has not been anything reported on that in a while either, though I think you only get 3DES if I recall correctly.

    • Particularly when using Krb5 for session encryption ;-) Of course how many slashdotters know that you can use telnet with session encryption on an intranet? Slim to none?

      • Re: (Score:3, Insightful)

        by drinkypoo ( 153816 )

        Any of them that have successfully set up IPSEC? I've used it to secure an application which screen-scrapes a telnet session and uses ftp to transfer files.

  • SSH standard (Score:5, Informative)

    by jgtg32a ( 1173373 ) on Thursday May 21, 2009 @01:50PM (#28043753)
    From the article it seems that it is more of a design flaw of SSH and not specifically OpenSSH

    And in other news it also appears that the word "chink" is banned in the comments section.

  • Design flaw (Score:5, Interesting)

    by aaronfaby ( 741318 ) on Thursday May 21, 2009 @01:52PM (#28043813)
    If the flaw is in the design of SSH, wouldn't all OS's be effected? Why does this only effect Debian?

  • OKay (Score:3, Funny)

    by JamesP ( 688957 ) on Thursday May 21, 2009 @01:52PM (#28043823)

    The 2^-18 is _really_scary_

    The 'first 4 bytes', not so much.

    So, meh. Of course true hardcore cryptanalysts are sure to be already ditching OpenSSH or maybe piping it through GPG first.

    • Re:OKay (Score:4, Informative)

      by characterZer0 ( 138196 ) on Thursday May 21, 2009 @01:55PM (#28043895)

      Being able to determine the first four bytes is what makes it 2^-18 instead of something much much smaller.

    • Nah, we'll just be using an up-to-date OpenSSH. On my Ubuntu boxes, it's already 5.1, whereas the tested version was 4.7.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      The 2^-18 is _really_scary_

      The 'first 4 bytes', not so much.

      So, meh. Of course true hardcore cryptanalysts are sure to be already ditching OpenSSH or maybe piping it through GPG first.

      Fuck gubfr onfgneqf, ebg13 vf tbbq rabhtu sbe nalbar.

      captcha: rotator

      • Re:OKay (Score:5, Funny)

        by swillden ( 191260 ) <shawn-ds@willden.org> on Thursday May 21, 2009 @03:27PM (#28045285) Journal

        The 2^-18 is _really_scary_

        The 'first 4 bytes', not so much.

        So, meh. Of course true hardcore cryptanalysts are sure to be already ditching OpenSSH or maybe piping it through GPG first.

        Fuck gubfr onfgneqf, ebg13 vf tbbq rabhtu sbe nalbar.

        Allow me to translate:

        $ echo "Fuck gubfr onfgneqf, ebg13 vf tbbq rabhtu sbe nalbar." | caesar
        Shpx those bastards, rot13 is good enough for anyone.

  • Wait, what? (Score:5, Insightful)

    by JSBiff ( 87824 ) on Thursday May 21, 2009 @01:53PM (#28043833) Journal

    ". . .discovered a flaw in Version 4.7 of OpenSSH on Debian/GNU Linux."

    "The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH"

    So which is it, is it an implementation specific bug, which is specific to OpenSSH on Linux specifically, OpenSSH on all O/Ses, or is it a flaw in the RFC, which should make it exploitable on *all* implementations of SSH, shouldn't it? How can a flaw in the standard only be exploitable in one version of one implementation of the standard on one specific target OS?

    • Re: (Score:2)

      by dave562 ( 969951 )
      Take a look at all of the uproar over Microsoft's interpretation of the ODF standard and it's pretty easy to see how different developers can take something that is "the same" and make it "different".

    • Re: (Score:3, Insightful)

      by Lord Ender ( 156273 )

      Standards don't necessarily define all behavior an application. Therefore, some versions will dance to the hackers tune when fed bad data, while others may not.

      • Re: (Score:2)

        by JSBiff ( 87824 )

        I agree with you there - but you generally wouldn't say that an undefined behavior which doesn't contradict the standard, but also isn't specified by the standard, is a problem with the standard itself. Since the security researcher said it was a problem with the standard itself, seems like that would mean that any *conforming* implementation of that standard would be affected by such a problem.

    • Re: (Score:3, Informative)

      by Jonner ( 189691 )

      This is not in the least insightful. If you read TFA, you'll see that since the flaw is in the standard specification, it does affect all implementations. The article doesn't say the flaw is only on Debian; it says that's where the flaw was found.

      • Re:Wait, what? (Score:5, Insightful)

        by JSBiff ( 87824 ) on Thursday May 21, 2009 @03:57PM (#28045653) Journal

        I *did* read the TFA, and it really wasn't clear in the article at all. Why even bother mentioning Debian and Linux, if the problem was an SSH problem, and not at all specific to Debian or Linux? Seems like it was just a somewhat poorly written article, adding confusion where there didn't have to be. People will take away from this that this is a Linux problem, and might not consider the possibility that, e.g. Mac OS X (which I believe includes some version of OpenSSH) may *possibly* be shipping an affected version of the software (I'm not saying it is, I'm just saying that the article author wrote the article in such a way that it appears the problem is strongly linked to Linux, when it sounds, upon further examination, like it isn't).

        It's really not definitive from the article whether or not other implementations are or might be affected, despite your assertion.

    • Re: (Score:2)

      by mzs ( 595629 )

      They mention Debian and 4.7p1 since that is what the researchers targeted. It was not fixed until 5.2. For various reasons Debian will not go past 4.7 for a while yet.

      The flaw is in the RFC since 4251 says that the server has to communicate the fact that there was an error. OpenSSH would communicate that as soon as it noticed. By the attacker replaying data slowly it could figure-out out bits in the plaintext. Now OpenSSH waits until it gets a lot of data before it responds. See not every implementation nee

      • For various reasons Debian will not go past 4.7 for a while yet.

        Debian isn't even distributing 4.7p1 anywhere, anymore (Packages of 5.1 were released on the 25th of July, 2008). 5.1p1-5 is in all of stable, testing and unstable, and etch (oldstable) is running 4.3p2-9etch3.

        That said, these are presumably all vulnerable, and patches which change the prefered cypher to non-vulnerable ones, and apply countermeasures by continuing to read until the maximum packet length is reached as detailed in the 5.2 release

    • How can a flaw in the standard only be exploitable in one version of one implementation of the standard on one specific target OS?

      OpenSSH is the Highlander. There can be only one. Debian is now decapitated.

  • How vulnerable? (Score:3, Informative)

    by Anonymous Coward on Thursday May 21, 2009 @01:53PM (#28043851)

    According to TFA, "OpenSSH version 5.2 contain[s] countermeasures". For Ubuntu users, note that Ubuntu 8.04 LTS (Hardy) is using [ubuntu.com] the vulnerable version 4.7. Versions 8.10 (Intrepid) [ubuntu.com] and above [ubuntu.com] appear to use version 5.1.

    Does anyone know whether 5.1 contains the flaw and/or the "countermeasures"?

    Also, can any security gurus comment on the danger level here? It sounds like there is a low-probability to access a small amount of information... but the very existence of this vulnerability makes me uncomfortable. Also, why does it mention Debian specifically? Don't most distros use an OpenSSH package based on the exact same design? Shouldn't they all be vulnerable?

    • Re:How vulnerable? (Score:5, Informative)

      by vadim_t ( 324782 ) on Thursday May 21, 2009 @02:39PM (#28044601) Homepage

      That's the wrong way to check it.

      Debian and Ubuntu are not going to upgrade to 5.2. They will take the security fix, backport it to 4.7, and release that as an update. If you check the version you'll get 4.7, even with the fix applied.

      • Re: (Score:3, Insightful)

        by Lord Ender ( 156273 )

        And security scanners are going to misreport the systems with backported patches as being vulnerable :-/

        • Re:How vulnerable? (Score:5, Insightful)

          by chrysalis ( 50680 ) on Thursday May 21, 2009 @04:31PM (#28046073) Homepage

          If your security scanner reports a vulnerability based on banners instead of testing the real flaw, they are flawed.
          Such security scanners feed the myth that changing/removing banners magically makes your network secure.

          • Re: (Score:3, Interesting)

            by Lord Ender ( 156273 )

            Are you kidding? Security scanners can't go around overflowing buffers as part of a routine test. This could take down your entire network! Honestly...

      • Debian and Ubuntu are not going to upgrade to 5.2. They will take the security fix, backport it to 4.7, and release that as an update. If you check the version you'll get 4.7, even with the fix applied.

        I can understand why Ubuntu would do that since it's an LTS, but Debian stable (which is what Ubuntu would call an LTS) is already on 5.1p1.

        • Re: (Score:3, Informative)

          by vadim_t ( 324782 )

          Debian stable is stable. Once it gets released it doesn't upgrade software to new versions or get new features. It gets bug fixes and security updates and that's it.

          If you want a newer version of anything on Debian stable, you have to switch to testing, use a mixed stable/testing system, wait for the next stable release, build it yourself, or use somebody else's packages.

          There are distributions like Gentoo which don't follow this model and continously release new versions.

    • Re: (Score:2)

      by mzs ( 595629 )

      Basically only CBC is vulnerable, so they prefer others. Also they now read the maximum size before returning an error. There still is a very slight information leak from timing analysis but it would make the chances much much smaller, to the point that it is now an infeasible attack:

      http://www.openssh.com/txt/release-5.2 [openssh.com]

      Security:

      * This release changes the default cipher order to prefer the AES CTR
      modes and the revised "arcfour256" mode to CBC mode ciphers that are

  • Original advisory (Score:5, Informative)

    by againjj ( 1132651 ) on Thursday May 21, 2009 @01:56PM (#28043901)
    http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt [cpni.gov.uk]

  • Which is it? (Score:3, Insightful)

    by glwtta ( 532858 ) on Thursday May 21, 2009 @01:56PM (#28043909) Homepage
    So is it a flaw in the design of SSH or in the Debian patched OpenSSH implementation? If it's the former (as the quote seems to imply), why does it matter what SSH implementation, OS they found it on? Shouldn't it affect everyone?

  • Some Additional Perspective FTA (Score:4, Insightful)

    by Fantom42 ( 174630 ) on Thursday May 21, 2009 @01:58PM (#28043945)

    FTA, this vulnerability is addressed in newer versions of OpenSSH, not by fixing the specification, but by employing some kind of workaround to make it impractical. I didn't know that from the summary, since I don't really keep current on where OpenSSH is with their releases.

    It seems like this attack has an awfully small chance of success. I am wondering if there is that small chance of success to decode a message after many days, or if because of the small chance of success, it would take multiple days before you had anything.

    If this is really something that has almost no chance of working at all--period, I'm not too worried. If it is something that makes the encryption breakable in a few days, that's a pretty big deal and am surprised that it didn't get outed sooner as a flaw.

    Can/should the RFC be revised to close this hole? Are there other (perhaps more obvious) examples of weakness in the RFC that have implementation-specific fixes applied?

  • Why so much press on this? (Score:5, Informative)

    by spinkham ( 56603 ) on Thursday May 21, 2009 @01:58PM (#28043947)

    This flaw was published in Nov 2008 with simple configuration fix, and OpenSSH released a default fixed version in March 2009.
    Also, this attack gives only 4 bytes of unencrypted output after crashing your session many thousands of times, which is sure to be noticed. If you were repeating the exact same network traffic in millions of SSH sessions, an attacker might get something interesting after weeks of crashing your sessions. It's just one of the lamest exploits I've seen, worth mitigating eventually, but not worth all the press it's getting, especially 6 months after release...
    The fix is simple, just use CTR mode encryption instead of CBC, or upgrade to OpenSSH 5.2 or later.
    For more details go to the OpenSSH security page. [openssh.com]

    • Re:Why so much press on this? (Score:4, Interesting)

      by mr_mischief ( 456295 ) on Thursday May 21, 2009 @02:06PM (#28044085) Journal

      Noticed? A good firewall that is updated regularly by a traffic analyzer should have a rule set to drop or deny the retransmissions after the first few. I guess we could have a philosophical debate about whether running code "notices" something when it matches a pattern and crosses a threshold to trigger a rule. "Notice" to me usually connotes sentience, or at least animal consciousness.

  • To those wondering why they mention Debian (Score:5, Informative)

    by cptnapalm ( 120276 ) on Thursday May 21, 2009 @01:59PM (#28043963)

    It is because that happened to be the system that they found the vulnerability on.

    Nothing more than that, really.

    • Re:To those wondering why they mention Debian (Score:4, Interesting)

      by Pretzalzz ( 577309 ) on Thursday May 21, 2009 @03:14PM (#28045145)
      All current versions of Debian have 5.1p1-5 as the version of openssh[testing/unstable differences are just dependency rebuilds].

      The changelog for this version includes:

      * Backport from upstream CVS (Markus Friedl):

      - packet_disconnect() on padding error, too. Should reduce the success probability for the CPNI-957037 Plaintext Recovery Attack to 2^-18.

      This implies that older versions are more vulnerable. Not sure if this is what people are referring to as 5.2's countermeasures.

  • ftfa:
    "The flaw, which lies in version 4.7 of OpenSSH on Debian/GNU Linux"
    "Patterson said his group had worked with OpenSSH developers to mitigate the flaw, and that OpenSSH version 5.2 contained countermeasures."

    They are unclear on whether or not it's only debian's repos that are affected, so I'd suggest upgrading to 5.2 or later.
  • Command to determine openSSH version: ssh -V Output: OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 I assume if you get the same results as I did you are not affected because you are running version 5.1.

  • Need to be worried? (Score:3, Interesting)

    by gmuslera ( 3436 ) on Thursday May 21, 2009 @02:30PM (#28044443) Homepage Journal
    Implies man-in-the-middle already, and the odds of figuring 32 bits of a particular packet are somewhat low. The worst case i could think about is when i pass my password or a very specific short data (cc number?). That particular data must be the decripted one, and in the 1/256k odds of happening, IF i have someone in the middle actively trying to get it. With that chances, the attacker well could expend his time playing lotto that have more chances to win.

    Of course, those numbers are regarding a specific distribution/ssh version, could be different for other versions, but still, looks somewhat hard to happen ever.

  • > Patterson said that he did not believe this flaw
    > had been exploited in the wild, and that to
    > deduce a message of appreciable length could take
    > days.

    Is my social security number a "message of appreciable length?"

    • Is your social security number a secret?

      I understand you don't want to have it flying around, because some people use it as a secret. But it's not a secret in the first place, and there are many more likely attack vectors for your SSN than hijacking an SSH session.

    • Re:Appreciable length? (Score:4, Informative)

      by asdf7890 ( 1518587 ) on Thursday May 21, 2009 @03:26PM (#28045267)

      > Patterson said that he did not believe this flaw > had been exploited in the wild, and that to > deduce a message of appreciable length could take > days.

      Is my social security number a "message of appreciable length?"

      Probably not on its own. Full packed it would take 33 bits, 11 bytes (88 bits, though if the attacker knew for sure that an SSN was being sent in those bytes the search space would not significantly greater than the 33 bits) if represented in pure ASCII text with separators.

      As each attempt to read each 32 bits has a 11/2^18 chance of success, and assuming failure of one attempt does no extra clue as to which other patterns to try next, each 4 byte block is going to take on average 131,072 connections to infer from the server response so for the 11 byte ASCII string that is an average attack length of 393,216 connections.

      While that isn't going to take long (at 4.5 connections per second you are looking at a day), any message being sent containing your SSN is going to be significatly longer than the SSN on its own so I wouldn't worry just yet.

      We are still in "it would be a lot easier for the attacker to raid your bins, burgle your house, or steal records from your bank" territory here. Though there is the chance that someone improve the attack (or already has) so be vigilant and apply updated SSH packages as soon as practical once your distribution offers them.

  • I can't find a reference to it. Certainly they submitted a bug report. They mention they found it on debian, so it seems like they would have file one.

  • It passed the decrypted packet_length value back to the other end in an error message, according to the article. Shouldn't that have allowed arbitrary recovery of plaintext by just xoring the returned packet length with the previous ciphertext block used as the IV?

Slashdot Top Deals

The opossum is a very sophisticated animal. It doesn't even get up until 5 or 6 PM.

Close