Chink in encryption armor discovered
Summary
Topics
The flaw, which lies in version 4.7 of OpenSSH on Debian/GNU Linux, allows 32 bits of encrypted text to be rendered in plaintext, according to a research team from the Royal Holloway Information Security Group (ISG).
An attacker has a 2^{-18} (that is, one in 262,144) chance of success. ISG lead professor Kenny Patterson told ZDNet UK last Monday that the flaw was more significant than previous vulnerabilities in OpenSSH.
"This is a design flaw in OpenSSH," said Patterson. "The other vulnerabilities have been more about coding errors."
According to Patterson, a man-in-the-middle attacker could sit on a network and grab blocks of encrypted text as they are sent from client to server. By re-transmitting the blocks to the server, an attacker can work out the first four bytes of corresponding plaintext. The attacker can do this by counting how many bytes the attacker sends until the server generates an error message and tears down the connection, then working backwards to deduce what was in the OpenSSH encryption field before encryption.
The attack relies on flaws in the RFC (Request for Comments) internet standards that define SSH, said Patterson.
Patterson gave a talk on Monday at the IEEE Symposium on Security and Privacy in California to explain his group's research findings. The three ISG academics involved in the research were Patterson, Martin Albrecht and Gaven Watson.
This vulnerability was first made public in November 2008 by the UK Centre for the Protection of National Infrastructure (CPNI), although full details of the flaw were not then given. According to the CPNI advisory, the OpenSSH flaw could be mitigated by IT professionals using AES in counter mode (CTR) to encrypt, instead of cipher-block chaining mode (CBC).
Patterson said his group had worked with OpenSSH developers to mitigate the flaw, and that OpenSSH version 5.2 contained countermeasures.
"They've fixed [OpenSSH]; they've put countermeasures in place to stop our attack," said Patterson. "But the standard has not changed."
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. In addition, proprietary SSH vendors had been informed of the issue in advance, and had put countermeasures in their code. However, Patterson added that it always takes time for sysadmins to apply patches to servers and clients, no matter whether the software is open source or proprietary.
This article was originally posted on ZDNet UK.
Just In
describe a kink in armor?
Unless of course this is a racial slur aimed at
Chinese hackers. Maybe I should read the
article before I comment.
(meaning 1 - "a crack, cleft, or fissure: a chink in a wall.")
Kink is practically synonymous in the context, but there's absolutely nothing wrong with the world used in this article (just something wrong with the over-the-top racism filter on comments).
Chink is more appropriate to the armour metaphor.
the whole problem with politically correct speach is that if politics is the art of compromise and one is already correct, there is no room for compromise. therefore it is all politically wrong.
ZDNET QUIT TRYING TO BE SO POLITICALLY CORRECT!
gosh that hallarious... I've seen it happen before on
a ZDNet blog, but I don't remember what word.
Sounds dangerous.........
For the OpenSSH users
http://www.cpni.gov.uk/docs/vulnerability_advisory_ssh.txt
There's no protocol called "Open Secure Shell". SSH is the protocol name, OpenSSH is an implementation. It's 2009 and we still don't have any tech journos who can write cogently about this kind of crap? Unreal.
Nice to see OpenBSD do this, even though the [IETF?] hasn't changed the 'standards' flaw(s) in those RFC's.
My $0.02.
www.openssh.org
Join the conversation!
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox




