Discussion:
openSSH and SLOTH vulnerability
(too old to reply)
Sandeep Umesh
2016-01-18 09:39:30 UTC
Permalink
Hi

I got 2 questions related to info in the SLOTH article, can someone help
with these?
1. For SSH2 exposure for the (CVE-2015-7575) SLOTH (
http://www.mitls.org/pages/attacks/SLOTH), the chart in that URL
identifies a downgrade attack for SSH2 protocol, Key Exchange Integrity
SHA1. Is the remediation for that vulnerability to modify the config
files to remove the MD5 and SHA1 as MAC's (Message Authentication Codes) ?

2. Is there any exposure related to using the ssh-keygen for the initial
creation of the public/private key pairs or the exposure of the related
fingerprint used (https://en.wikipedia.org/wiki/Public_key_fingerprint) ?

Thanks


Regards
Sandeep
Jakub Jelen
2016-01-18 15:21:42 UTC
Permalink
Post by Sandeep Umesh
1. For SSH2 exposure for the (CVE-2015-7575) SLOTH (
http://www.mitls.org/pages/attacks/SLOTH), the chart in that URL
identifies a downgrade attack for SSH2 protocol, Key Exchange Integrity
SHA1. Is the remediation for that vulnerability to modify the config
files to remove the MD5 and SHA1 as MAC's (Message Authentication Codes) ?
No. It is not about HMACs used in the transport protocol,
but about DH authentication codes. They are
part of the KEX algoritms, such as diffie-hellman-group1-sha1 or
diffie-hellman-group-exchange-sha256, where the SHA1 is vulnerable to
downgrade attack, as described in the paper [1]. You can remove
diffie-hellman-group14-sha1 from default KexAlgorithms list,
but you might end up not able to connect to some servers.
Post by Sandeep Umesh
2. Is there any exposure related to using the ssh-keygen for the initial
creation of the public/private key pairs or the exposure of the related
fingerprint used (https://en.wikipedia.org/wiki/Public_key_fingerprint) ?
This is completely unrelated. Attacker as a MitM can tamper with
both client and server cipher-suites during key exchange and might
downgrade the negotiate ciphersuite to a weak cryptographic algorithm
that he knows how to break. It is based on the knowledge of server and
client identification strings, if I am right.

It is still more theoretical since it needs a lot of work per connection
(2^77),
which is less then the 2^160 as should sha1 provide, but still more than is
should feasible.

Feel free to correct me if I read the report wrong at some point.

[1] http://www.mitls.org/downloads/transcript-collisions.pdf

Regards,
--
Jakub Jelen
Security Technologies
Red Hat
Loading...