Your message dated Sun, 29 Sep 2024 14:20:45 +0100
with message-id <zvlulsodtrqvb...@riva.ucam.org>
and subject line Re: Bug#1082728: openssh: Passive SSH Key Compromise via
Lattices (RSA host keys)
has caused the Debian Bug report #1082728,
regarding openssh: Passive SSH Key Compromise via Lattices (RSA host keys)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1082728: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082728
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openssh
Version: 1:9.9p1-1
Severity: grave
The paper,
Passive SSH Key Compromise via Lattices
Keegan Ryan, Kaiwen He, George Arnold Sullivan, and Nadia Heninger
https://eprint.iacr.org/2023/1711.pdf
details an attack that allows a passive observer to potentially
compromise RSA host keys. They also include details on internet-wide
scans to measure the prevalence of vulnerable signatures in the wild.
I'm not aware if there is a CVE for this yet. The only other reference I
have seen to it is this commit
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/e3f33c64ec168a48038309af0c237eda86d10c74
--
Matt Taggart
m...@lackof.org
--- End Message ---
--- Begin Message ---
On Wed, Sep 25, 2024 at 12:32:56AM -0700, Matt Taggart wrote:
> Sorry, I should have read the whole thing before filing the bug...
>
> Section 5.1 says: not an issue on openssh because it uses openssl to
> generate signatures and openssl has had countermeasures for this since 2001.
> So hopefully that is enough....
>
> Section 5.2 says: openssh 8.8 deprecated "ssh-rsa" (sha1), but
> "rsa-sha2-256" and "rsa-sha2-512" remain.
>
> I am a bit confused as to what controls this in sshd_config. I see:
>
> HostbasedAcceptedAlgorithms: signature algorithms that will be accepted for
> host based authentication
> HostKeyAlgorithms: host key signature algorithms that the server offers
>
> and the manpage entry for those has lists that do NOT contain ssh-rsa.
>
> However, running `ssh -Q` for each of these on my bookworm
> (1:9.2p1-2+deb12u3) system still lists `ssh-rsa` and
> `ssh-rsa-cert-...@openssh.com`. Are they really still available?
"ssh -Q" tells you about _supported_ algorithms rather than _enabled_
algorithms. You can still explicitly ask for these, but they're
disabled by default in both the client and the server (as of OpenSSH
8.8, I think). They won't be used unless they're the most-preferred
algorithm out of those supported by both the client and the server.
HostKeyAlgorithms is the relevant sshd_config option here. You can use
"sshd -G | grep ^hostkeyalgorithms" to see what a server is configured
to offer (or -T instead of -G if you're on <9.3 and can run that command
as root).
> As for RSA keys, existing RSA host keys still function and I don't think
> there has been any call to deprecate RSA as a key type, or even stop
> generating and using it by default on new installs. I'm not sure what those
> HardenedBSD folks are thinking...
My best guess is that the theory is as follows: if you've been
systematically recording traffic from a given host, then you might have
some faulty signatures from existing keys that you could use to derive
the private key as per this paper.
However, unless you're sharing host keys between implementations (surely
rare), for this to be a viable attack against OpenSSH, the attacker
would have to have stored traffic from before 2001 when OpenSSL started
validating signatures before sending them. This is surely vanishingly
rare - not so much "nation-state attack" as "attack by the Blight" [1].
Also, as of OpenSSH 8.7, clients normally accept updates of host keys
from servers (subject to some preconditions - see the release notes for
that version). So if you've ever connected with at least that version,
and if the server administrator hasn't gone out of their way to remove
Ed25519/ECDSA host keys, then the client will know about a
more-preferred host key and will use it instead of RSA anyway.
[1] https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep
> So I think this is not severity grave and also I'm not sure if there is
> anything to do here. The authors make the point that there is a huge
> installed base still using ssh-rsa, but for Debian hosts they A) are likely
> not vulnerable due to 5.1 above and B) if they were, the way to fix them
> would probably be upgrading to 8.8+?
Indeed. To the extent that Debian-based systems contribute to that
installed base, it'll mostly be Debian < 12 and Ubuntu < 22.04. (Cases
where people have explicitly re-enabled old algorithms to talk to old
hosts will almost certainly be statistical noise, and probably mostly on
private networks.)
> But is there anything about mixed interactions that Debian should be doing?
> What is the current (and also expected) behavior of:
> * newer Debian client connecting to older rsa-sha server
https://www.openssh.com/legacy.html doesn't explicitly mention rsa-sha,
but it's essentially the same deal. If there are no mutually-acceptable
algorithms then the connection fails.
But for OpenSSH the server would have to be very old indeed:
rsa-sha2-{256,512} were added in OpenSSH 7.2, but even before that there
were ssh-ed25519 (added in OpenSSH 6.5) and
ecdsa-sha2-nistp{256,384,521} (added in OpenSSH 5.7), all of which will
be preferred over their RSA equivalents by current OpenSSH clients if
the corresponding host key is available.
> * older rsa-sha client connecting to newer Debian server
Pretty much symmetrical with the above, except that in that case you
wouldn't be able to get out of it by adjusting client configuration and
would have to upgrade the client instead. Assuming the default set of
server host keys, I believe that upgrading would only be absolutely
required if the client were older than OpenSSH 5.7 (released in 2011).
In conclusion, I think there's nothing that makes sense for Debian to do
here, so I'm closing this bug. But thanks for the interesting paper,
which I hadn't previously seen.
--
Colin Watson (he/him) [cjwat...@debian.org]
--- End Message ---
