Flaw in encryption armor discovered
Correction at 5:50 a.m. PDT May 20: The spelling of Kenny Paterson's last name has been corrected.
An underlying flaw in the widely used encryption protocol Open Secure Shell (OpenSSH) has been made public by researchers from the Royal Holloway, University of London.
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 one in 262,144 chance of success. ISG lead professor Kenny Paterson told CNET News sister site ZDNet UK last Monday that the flaw is more significant than
"This is a design flaw in OpenSSH," said Paterson. "The other vulnerabilities have been more about coding errors."
According to Paterson, 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 retransmitting 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 backward 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 Paterson.
Paterson gave a talk on Monday at the IEEE Symposium on Security and Privacy in Oakland, Calif., to explain his group's research findings. The three ISG academics involved in the research were Paterson, 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), though 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 (advanced encryption standard) in counter mode (CTR) to encrypt, instead of cipher-block chaining mode (CBC).
Paterson 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 Paterson. "But the standard has not changed."
Paterson 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, Paterson added that it always takes time for system administrators to apply patches to servers and clients, no matter whether the software is open source or proprietary.
Tom Espiner of ZDNet UK reported from London.
Re: patches, what bothers me is that there are various devices that are not so easily patched, ie various sorts of network equipment that have SSH functionality in an OS embedded in firmware, that might not be so easily updated.
"Days" to successfully break a security barrier is nothing if an attacker really wants something from the attacked entity. Most encryption protocols are considered insecure if a brute-force attack takes anything less than many years to succeed, using hardware available on the consumer market.
You're digging up a vulnerability that was discovered six months ago, dealt with six months ago, and then classifying it as a vulnerability in the "OpenSSH Protocol"? OpenSSH is an implementation, not a protocol. How is this story possibly helpful?
I got pointed to your article by a manager who wanted to make sure our "OpenSSH Protocol" was secure. Thanks again, CNET, for causing FUD in mid-level bureaucrats.
- by RobertAPierce May 19, 2009 1:49 PM PDT
- What a poorly researched article, apparently written by someone who doesn't really undertand the subject matter.
- Like this Reply to this comment
-
(4 Comments)