Contributed by ray on from the DON'T-PANIC! dept.
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)

By Alex Hafey (199.67.138.153) on
At least one implementation has been given this, why not OpenSSH?
I'm not far away from these guys, just let me know ;-)
Comments
By Marc Espie (213.41.185.88) espie@openbsd.org on
>
> 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
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 2007So yes, looks very much like empty red tape to try and protect their asses... Warning: large empty dumb void inside.
Comments
By Anonymous Coward (87.144.88.30) on
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
By Otto Moerbeek (otto) on http://www.drijf.net
> 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
By Chris Wareham (80.176.91.102) chriswareham@chriswareham.demon.co.uk on www.chriswareham.demon.co.uk
> > 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
By Anonymous Coward (128.171.90.200) on
Comments
By Anonymous Coward (74.13.28.37) on
No, it simply has poor priorities.
By Anonymous Coward (66.42.183.199) on
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
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
By Dmitri Alenichev (mitya) on http://rootshell.be/~mitya/
everybody can read email ;-)
Comments
By Terrell Prude' Jr. (151.188.18.46) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
>
> everybody can read email ;-)
And everybody can also read PDF. :-)
By Terrell Prude' Jr. (151.188.18.46) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
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