OpenBSD Journal

Damien Miller (djm@) Responds to Plaintext Recovery Attack Against SSH

Contributed by ray on from the DON'T-PANIC! dept.

Damien Miller (djm@) issued the following advisory regarding the recent attack against SSH:

OpenSSH Security Advisory: cbc.adv

Regarding the "Plaintext Recovery Attack Against SSH" reported as CPNI-957037:

The OpenSSH team has been made aware of an attack against the SSH protocol version 2 by researchers at the University of London. Unfortunately, due to the report lacking any detailed technical description of the attack and CPNI's unwillingness to share necessary information, we are unable to properly assess its impact.

Based on the description contained in the CPNI report and a slightly more detailed description forwarded by CERT this issue appears to be substantially similar to a known weakness in the SSH binary packet protocol first described in 2002 by Bellare, Kohno and Namprempre. The new component seems to be an attack that can recover 14 bits of plaintext with a success probability of 2^-14, though we suspect this underestimates the work required by a practical attack.

For most SSH usage scenarios, this attack has a very low likelihood of being carried out successfully - each attempt has a low probability of success and each failure will cause connection termination with a fatal error. It is therefore very unlikely for an interactive session to be usefully attacked using this protocol weakness: an attacker would expect around 11356 connection-killing attempts before they are likely to succeed. This level of disruption would certainly be noticed and it is highly unlikely that any user would retry the connection enough times for the attack to succeed.

The usage pattern where the attack is most likely to succeed is where an automated connection is configured to retry indefinitely in the event of errors. In this case, it might be possible to recover on average 44 bits of plaintext per hour (assuming a very fast 10 connections per second). Implementing a limit on the number of connection retries (e.g. 256) is sufficient to render the attack infeasible for this case.

AES CTR mode and arcfour ciphers are not vulnerable to this attack at all. These may be preferentially selected by placing the following directive in sshd_config and ssh_config:

Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

A future version of OpenSSH may make CTR mode ciphers the default and/or implement other countermeasures, but at present we do not feel that this issue is serious enough to make an emergency release.

Thanks, Damien, for clarifying this issue. I'm sure many were concerned, but don't worry! You're in good hands.

Update: Markus Friedl (markus@) committed a change to further reduce the likelihood of this attack:

CVSROOT:        /cvs
Module name:    src
Changes by:     markus@  2008/11/21 08:47:38

Modified files:
       usr.bin/ssh    : packet.c

Log message:
packet_disconnect() on padding error, too.  should reduce the success
probability for the CPNI-957037 Plaintext Recovery Attack to 2^-18
ok djm@

Update 2: Damien updated the advisory:

This is the second revision of this advisory, correcting an error in the estimated number of connection attempts required for a successful attack.

(Comments are closed)


Comments
  1. By Alex Hafey (199.67.138.153) on

    WTF, what ever happened to "full disclosure"?

    At least one implementation has been given this, why not OpenSSH?

    I'm not far away from these guys, just let me know ;-)

    Comments
    1. By Marc Espie (213.41.185.88) espie@openbsd.org on

      > WTF, what ever happened to "full disclosure"?
      >
      > At least one implementation has been given this, why not OpenSSH?
      >
      > I'm not far away from these guys, just let me know ;-)

      I really should make an habit of keeping copies of webpages when
      they first appear.

      From what I recall, there is some SERIOUS retcon going on. Specifically, I distinctly recall the first version of the advisories did say that `vendors have been notified'... which is obviously wrong, as you can see.

      I'm seriously peeved about the current security market. It seems those guys are fairly desperate to be the FIRST to publish a security vulnerability, to the extent that they will even FOREGO communicating with the actual team that develops the software.

      So, to cut to the chase, I believe those guys don't give a FUCK about the security of computer systems. All they care about is their precious list of publications... Otherwise, Damien would already be 100% aware of all the details of the attack...

      Wow. You live near them ? feel free to copy/paste and give them this text. I'd be DELIGHTED to learn what they have to say about this.

      WITHOUT any legalese, nor other crap. Why don't they play with us ? Damien and friends gave them openssh... NOT debian, NOT any other vendor...


      Comments
      1. By Marc Espie (213.41.185.88) espie@openbsd.org on

        Okay, I've been informed Theo got some "information" from CPNI... He told us to repost that information on mailing-lists.

        Here follows a copy of the document (the original is a pdf, but fortunately, we have tools to extract text from that).

                 Centre for the Protection of National
                                  Infrastructure
              Framework for Vulnerability Information
                                       Sharing
        Introduction
        
        CPNI was formed from the merger of the National Infrastructure
        Security Co-ordination Centre (NISCC) and the National Security
        Advice Centre (NSAC).
        
        CPNI provides integrated security advice (combining information,
        personnel and physical) to the businesses and organisations which
        make up the national infrastructure. Through the delivery of this
        advice, we protect national security.
        
        One of the primary CPNI functions is to establish long-term
        partnerships with those companies that provide CNI services. This
        relationship is reinforced on a regular basis by the provision of various
        CPNI advisory materials on IT-related threats and vulnerabilities.
        CPNI conducts extensive research into vulnerabilities, the results of
        which we share with both CNI organisations and product suppliers. To
        enable us to share such information in confidence, CPNI provides this
        non-legally binding Framework as a mechanism to establish trusted
        partnerships.
        
        This Framework is intended to help CPNI and commercial organisations
        to work in partnership to discuss and resolve issues arising from
        vulnerability disclosures. By adhering to this framework you will be
        part of a mechanism through which technical and commercial
        vulnerability information can be shared between partners.
        This Framework is intended to increase the flow of vulnerability
        information within a trusted environment whereby issues can be
        solved quickly and easily, while at the same time limiting the likelihood
        of uncontrolled public release.
        
        The Traffic Light Protocol
        
        CPNI has agreed a labelling mechanism known as the "Traffic Light
        Protocol" (TLP) with members of its Information Exchanges. This same
        protocol has now been accepted as a model for trusted information
        exchange by over 30 other countries. The protocol provides for four
        "information sharing levels" for the handling of sensitive information.
        The four information sharing levels are:
           #  RED - Personal for named recipients only. In the context of a
              meeting, for example, RED information is limited to those
              present. In most circumstances RED information will be passed
              verbally or in person.
           #  AMBER - Limited distribution. The recipient may share AMBER
              information with others within their organization, but only on a
              "need-to-know" basis.
           #  GREEN - Community wide. Information in this category can be
              circulated widely within a particular community. However, the
              information may not be published or posted on the Internet, nor
              released outside of the community.
           #  WHITE - Unlimited. Subject to standard copyright rules, WHITE
              information may be distributed freely, without restriction.
        
        Framework for the exchange of Vulnerability Information
        
        This framework is not a legal contract. It is a statement of the
        requirements for information sharing between CPNI and the receiving
        organisation.
        The Centre for the Protection of National Infrastructure (CPNI) and the
        receiving organization jointly agree:
           #  to label vulnerability information to be shared with one of the
              four "information sharing levels" identified in the Traffic Light
              Protocol (TLP);
           # where necessary and appropriate to protectively mark the
             information in line with their own internal security policies and in
             accordance with the TLP;
           # to use the same degree of care to maintain confidentiality of
             shared vulnerability information as is used for their own internal
             or commercially sensitive information;
           # neither directly nor indirectly disclose to a third party in advance
             of the agreed public disclosure date, either the existence of, or
             details pertaining to, vulnerability information supplied under
             this framework without the prior written approval of the
             originating organization;
           # not to use the vulnerability information disclosed for commercial
             advantage or marketing purposes;
           # to restrict the release of vulnerability information solely to those
             persons within the organization with a legitimate need to know
             by virtue of their job or role.            Such persons must be
             appropriately briefed on, and bound by, the meaning of the TLP
             sharing mechanism;
           # to destroy vulnerability information that is no longer required;
           # to disclaim liability for any damages arising from the use of the
             vulnerability information;
           # that access to vulnerability information is offered free of any
             financial charge and without warranty of any kind;
           # not to employ legal remedy to address any conflict arising from
             the disclosure or use of any vulnerability information provided.
        CPNI
        
        February 2007
        

        So yes, looks very much like empty red tape to try and protect their asses... Warning: large empty dumb void inside.

        Comments
        1. By Anonymous Coward (87.144.88.30) on

          > Warning: large empty dumb void inside.
          You should have written that at the top of your comment.
          Would have saved me several minutes figuring out what they are trying to say.
          Thanks for sharing anyway.

          Comments
          1. By Otto Moerbeek (otto) on http://www.drijf.net

            > > Warning: large empty dumb void inside.
            > You should have written that at the top of your comment.
            > Would have saved me several minutes figuring out what they are trying to say.
            > Thanks for sharing anyway.

            I can expect such documents from government institutions. But what I find worse is that the original researchers at the University of London that found the problem go along or even agree with this bureaucratic stuff that decreases security instead of increasing it.

            This goes so against the nature of a University. Knowledge should be shared, especially knowledge regarding vulnerabilities. It shows how corrupted researchers have become by making themselves dependent on businesses and governments.






            Comments
            1. By Chris Wareham (80.176.91.102) chriswareham@chriswareham.demon.co.uk on www.chriswareham.demon.co.uk

              > > > Warning: large empty dumb void inside.
              > > You should have written that at the top of your comment.
              > > Would have saved me several minutes figuring out what they are trying to say.
              > > Thanks for sharing anyway.
              >
              > I can expect such documents from government institutions. But what I find worse is that the original researchers at the University of London that found the problem go along or even agree with this bureaucratic stuff that decreases security instead of increasing it.
              >
              > This goes so against the nature of a University. Knowledge should be shared, especially knowledge regarding vulnerabilities. It shows how corrupted researchers have become by making themselves dependent on businesses and governments.
              >

              The researchers didn't make themselves dependent on business out of choice. The universities in the UK have always been dependent on government, and it is the government that is now forcing them to be dependent on business. Just like the public health system, partnerships with business are being foisted on institutions although it is contrary to their interest as public bodies.

              Frankly, as a graduate of the University of London - and one who spent his first year at Royal Holloway - this makes me very upset. The most frustrating thing is that now both of the major UK political parties support this inappropriate commercialisation of universities rather than encouraging a healthy research environment.

              Comments
              1. By Anonymous Coward (128.171.90.200) on

                I think the elephant-in-the-room is that the government cannot afford universities, it embraces the commercialisation out of necessity.

                Comments
                1. By Anonymous Coward (74.13.28.37) on

                  > I think the elephant-in-the-room is that the government cannot afford universities, it embraces the commercialisation out of necessity.

                  No, it simply has poor priorities.

  2. By Anonymous Coward (66.42.183.199) on

    Money. Simple, researcher need to validate some work and keep funding going.

    Distributors need to keep something going, so they validate anything.

    The security market is amazingly corrupt, and incompetent.

    We all know this. DJB, wants to put them all out of business.

    Look at what UK named group uses for communication to them, PGP Desktop 9.5.3. Enough said.

    What else would you expect? Also no real security people distribute info with pdf if they have a choice.

    Win doze idiots.

    USA CERT helped break up full disclosure by closing things up, and charging $. They made security worse, all this in 2003. Rise of Secunia proves this. See http://www.internetnews.com/dev-news/article.php/2170381

    FBI infraguard and others, grr, for those outside of USA, worked some ends for full disclosure to die off.

    While I expect most of undeadly readers to know this stuff, I post this as a record to outsiders, governments and groups have made security WORSE off, this is a 5 year later summary of how their bad their methods STILL are.

    What else would you expect from USA "influences"?

    Comments
    1. By kitche (71.243.190.83) on


      >
      > What else would you expect? Also no real security people distribute info with pdf if they have a choice.
      >

      umm real security people prefer pdf, since it is an open standard now and gives the pages wonderful output unless you want a real ugly email that no one can read like the SSH email that was sent out.

      Comments
      1. By Dmitri Alenichev (mitya) on http://rootshell.be/~mitya/

        > umm real security people prefer pdf, since it is an open standard now and gives the pages wonderful output unless you want a real ugly email that no one can read like the SSH email that was sent out.

        everybody can read email ;-)

        Comments
        1. By Terrell Prude' Jr. (151.188.18.46) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

          > > umm real security people prefer pdf, since it is an open standard now and gives the pages wonderful output unless you want a real ugly email that no one can read like the SSH email that was sent out.
          >
          > everybody can read email ;-)

          And everybody can also read PDF. :-)

    2. By Terrell Prude' Jr. (151.188.18.46) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

      > What else would you expect from USA "influences"?

      After the machinations of our current administration, I can't blame you for saying that. Yep, our government is plenty corrupt, as are all others. No, unfortunately, it's not unique to my country; Tony Blair of the UK and Alan Garcia of Peru are also "joined at the hip" to the likes of Bush. And Clinton was just as bad, I can assure you. Remember, he's the one who pushed that disgusting "Clipper" chip in 1993, and it was his administration that instigated that witch-hunt upon Phil Zimmerman for writing PGP.

      Lord Acton was right. Power tends to corrupt.

      The fact that my Congress just two months ago voted US $700 billion (thousand million) for fat cats on Wall Street is plenty proof for me just how big our problem is. And President-Elect Obama SUPPORTS this lunacy!! Oh, and this was totally against the stated wishes of the American people, BTW. We the people did *not* want them to do that. Matter of fact, there were millions of calls to Congress-critters telling them *not* to do that. But they did it anyway. The question is, will enough voters remember it two years from now when the midterm election comes around? Somehow, I doubt it.

      And as for "security" teams, the one I trust the most is the OpenBSD development team.

      --TP

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