New SSH Vulnerability

For the first time, researchers have demonstrated that a large portion of cryptographic keys used to protect data in computer-to-server SSH traffic are vulnerable to complete compromise when naturally occurring computational errors occur while the connection is being established.

[…]

The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined. That translates to roughly 1 billion signatures out of the 3.2 billion signatures examined. Of the roughly 1 billion RSA signatures, about one in a million exposed the private key of the host.

Research paper:

Passive SSH Key Compromise via Lattices

Abstract: We demonstrate that a passive network attacker can opportunistically obtain private RSA host keys from an SSH server that experiences a naturally arising fault during signature computation. In prior work, this was not believed to be possible for the SSH protocol because the signature included information like the shared Diffie-Hellman secret that would not be available to a passive network observer. We show that for the signature parameters commonly in use for SSH, there is an efficient lattice attack to recover the private key in case of a signature fault. We provide a security analysis of the SSH, IKEv1, and IKEv2 protocols in this scenario, and use our attack to discover hundreds of compromised keys in the wild from several independently vulnerable implementations.

Tags: academic papers, cryptography, signatures, SSH, vulnerabilities

Posted on November 15, 2023 at 12:51 PM • 6 Comments

Comments

Kai • November 15, 2023 5:21 PM

From what I’ve read elsewhere, this only affects certain closed-source implementations of the SSH protocol. OpenSSH is not affected.

carl carver • November 15, 2023 8:18 PM

I think the summary should’ve included this paragraph too:

The countermeasure to the attacks we describe in this paper is
well known: implementations should validate signatures before
sending them. OpenSSH, the most common SSH implementation
we observed in this data, implements this countermeasure because
it uses OpenSSL to generate signatures, and OpenSSL has included
countermeasures against RSA fault attacks since 2001.

Also: OpenSSH has been deprecating RSA in various ways, and real servers use error-correcting memory, so this mostly affects—surprise!—embedded devices (Zyxel, Mocana, Cisco). Many of which are probably not updated or not updateable, and full of flaws that would be much more embarrassing if the people involved had any sense of embarrassment. Try logging in with password “password” before getting cryptographers involved.

I’ll ask what seems like the obvious question raised by the above quotation: do OpenSSL and/or OpenSSH use such a countermeasure for their non-RSA algorithms, and should they?

Clive Robinson • November 15, 2023 10:23 PM

@ carl carver,

Re : Efficiency v. Security, resource and throughput questions.

“do OpenSSL and/or OpenSSH use such a countermeasure for their non-RSA algorithms, and should they?”

I’ve been asked asked similar “should they?” questions many times in the past…

I have always answered “yes” and engineers rarely question it, when they do a fairly simple example that takes only a few seconds to give generally gets them to see the point.

However… It’s rarely the engineers or security/privacy people that decide, because they are apparently not fit to make such judgments.

Managment almost always defers to Marketing and Sales, who are convinced that “specmanship sells” and security or privacy does not to anyone other than the “Government”. In fact these days I get the feeling more and more that certain manufacturers either also defer to “Golden Key” arguments from external entities, or are deliberately reckless for similar reasons.

In the past when hardware resources were not just eye wateringly expensive, but mind numbingly slow, the “Security v. Resources” argument had to fall towards the “Efficiency” side thus “Security v. Throughput” was the argument and throughput always won the argument.

The result was everything got stripped back to the bone or further. So “checking” was a luxury that was not going to happen.

Now you can spend a couple of bucks and get a “System On a Chip” microcontroller with peripherals that is as, if not more powerfull, than a 1970/80 top end maxed out “32bit Mini-computer” was and costing way more than a large house in the nicer parts of Silicon Valley…

That is there is no real reason not to do the checks that ensure that the “security is safe” thus “privacy is assured”.

Yet you will find that no matter which way you argue it many US Managment will argue against the checks… Eventually you get down to the facile “That’s the way we’ve always done it” style argument.

The only way to get them to change behaviour is,

“Name, Shame, and smite them right.”

Not just the corps but the managment members by name as well. Sufficient “negative publicity” in a campaigning framework where they find their chance of bonus etc gets reduced to negligible or less can be a motivator. It also improves the chance that they will be smitten by being on the wrong end of a class action law suit. Which can make financiers, venture capitalists, and even share holders wince and where they can walk and stay away.

One of the companies mentioned is now owned by DigiCert, which appears to have dropped more than one clanger as a CA and are marked as “untrusted” in my CA Cert list. So do not be surprised if “P155 P00r P3rf0rm4nce” is on it’s way down the turnpike.

Dave • November 15, 2023 11:56 PM

It’s not a new attack, it’s at least twenty years old, and any true Scotsman… I mean, decent implementation defended against it twenty years ago. Since some of the affected implementations still support SSHv1 they’ve (a) got bigger problems than a one-in-a-million fault and (b) probably haven’t been updated since Windows 98 was state of the art. So it’s not “New SSH attack” it’s “Ancient never-updated SSH implementations still vulnerable to equally ancient attack”.

ResearcherZero • November 16, 2023 2:18 AM

@carl carver

All the fun devices that you don’t want outside parties connecting to, that no one knows are connected to the internal networks, avoiding ‘bothersome’ maintenance.

carl carver • November 16, 2023 7:53 PM

I mean, decent implementation

A decent and recent implementation in the embedded world? You’re optimistic, Dave.

I just realized that I’m not using only OpenSSH as I thought: my OpenWRT router runs Dropbear. And while the code’s a bit hard to follow—libraries, function pointers, etc.—I haven’t yet found any evidence that it or libtomcrypt, which it uses, protect against this attack. Since I’m connecting with the OpenSSH client, which checks the host identity via its ed25519 key, I’m not sure there’s any real risk. I deleted all “ssh-rsa” lines from known_hosts anyway, just to be a bit safer (I don’t even know what they’re for, thanks to HashKnownHosts, and I can’t help but wonder whether plaintext hostnames or obsolete entries pose a bigger risk).

Clive is basically saying “always verify generated signatures before sharing them”. That seems reasonable. But does anyone know whether memory faults pose similar risks to, say, ed25519? It’s unclear whether the authors attacked RSA because it was uniquely vulnerable; maybe it’s just more common (especially in bad implementations or on bad hardware), better researched, or (due to the larger keys) more likely to be hit by errors.

New SSH Vulnerability

Comments

Leave a comment Cancel reply