SSH1 vulnerability ?
Tatu Ylonen
> I just read Razor's vulnerability advisory, as reported on slashdot.
> Any truth to it, or is it another wannabe ?
I suppose you are referring to this one:
> "Bindview released an advisory yesterday warning us that "[a]n
> integer-overflow problem is present in common code of recent
> ssh daemons, deattack.c, which was developed by CORE SDI to protect
> against cryptographic attacks on SSH protocol. [...] This effectively
> allows an attacker to overwrite arbitrary portions of memory"
SSH2 is not vulnerable to this issue at all. Thus, if you are
using ssh-2.4.0, or any earlier version of SSH2, you are safe.
The vulnerability only affects the SSH1 protocol. The bug in the deattack
code is probably genuine, and looks like a coding bug (16 bit int used
instead of 32 bit int). We have also committed a fix to the SSH1 source
tree (which is still used by many to implement compatibility
with the old SSH1 protocol during the transition to SSH2 - see
http://www.ssh.com/products/ssh/ssh2-ssh1-server-howto.html for
information on how to transition to SSH2 while still maintaining
compatibility with existing SSH1 clients).
The whole CRC32 vulnerability is once again a manifestation of certain
fundamental problems in the SSH1 key exchange and message authentication
mechanism. The SSH2 protocol was created to fix these (and other)
problems. The old SSH1 protocol is deprecated, and people are strongly
urged to move to using the SSH2 protocol.
The effect of this particular vulnerability is that it may allow a highly
advanced attacker to insert commands into an SSH1 session using an active
network-level attack together with a cryptographic attack. I consider
this something that needs to be fixed (the real fix is to move to SSH2),
but it is not an immediate threat.
BTW, some cryptographers that I know have been speculating whether it
would be possible to construct attack patterns that would get around the
CRC32 deattack mechanism entirely. The original CRC32 attack works
obtaining some known plaintext-ciphertext pairs, and constructing a
special pattern that defeats the CRC32 that was used as MAC in SSH1. The
deattack code detects the particular pattern used to defeat the CRC32
check. However, some people are speculating that there may be other
patterns (e.g. involving more known plaintext-ciphertext pairs) that would
also compensate for CRC32 but would not be detected by the deattack code.
I cannot confirm whether this is the case, but I personally do not fully
trust that the deattack code will be able to prevent all variations of the
attack (even without the bug in the deattack code). The real fix is to
move to using the SSH2 protocol.
Ssh-2.4.0 is available from www.ssh.com (or ftp://ftp.ssh.com/pub/ssh),
and is completely free for any use on Linux, FreeBSD, NetBSD, and OpenBSD,
as well as for use by universities and charity organizations, and for
personal hobby/recreational use by individuals.
Tatu
--
SSH Communications Security http://www.ssh.com/
SSH IPSEC Toolkit http://www.ipsec.com/
SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh
Frank Cusack
will reload due to this vulnerability (crc32 problem). All other versions
of their code are probably vulnerable, and their other devices
(eg ServerIron) are probably vulnerable also.
~f