I have an idea for a protocol extension to limit the exposure of the
complex crypto code in ssh servers. It's like tcp-wrappers, but based
on a secret token rather than IP address.
Patch against openssh-3.7.1p2:
http://nick.cleaton.net/openssh-cc-0.03.patch
Details
======
The "Connection Cookies" mechanism is an unofficial ssh protocol
extension designed to prevent attackers who are unable to packet sniff
legitimate sessions from exploiting future ssh server vulnerabilities.
The connection cookie is a shared secret, which the client sends to the
server very early in the conversation. Unless a valid cookie is received
the server drops the connection.
Since the connection cookie mechanism is simple, there is very little
server side code that can be exercised by an attacker without a valid
connection cookie.
Since the connection cookie is transmitted unencrypted, this extension
offers no extra protection against attackers who are able to packet sniff
legitimate sessions.
(very rough) Specification
=========================
An ssh server configured to require a connection cookie must prefix the
28-byte string "RequireSSHConnectionCookie\r\n" to its ident string.
An ssh client configured to send connection cookies must do so only if
it sees this extra line from the server. The client should then prepend
the 3-byte string "CC:" followed by the 32-byte connection cookie to
its
own version string.
All 32 bytes of the connection cookie must be non-whitespace printable
US-ASCII characters other than doublequote (0x22). This restriction is
intended to simplify the handling of connection cookie values in
configuration files.
If a digest of a passphrase is used as a connection cookie then the
passphrase should be both very hard to guess and uncorrelated with any
other passphrase, password or other sensitive information. Ssh clients
that accept such a connection passphrase and perform the digest
internally must use the MD5 digest algorithm and transmit the cookie as
a 32-byte lowercase hexadecimal string.
Disadvantages
============
There are a few ways in which an ssh server that requires connection
cookies may be less secure than one that does not:
There may be a vulnerability of some sort in the server side code that
checks the connection cookie. However, that code is very simple so
vulnerabilities are unlikely. The same applies to the client side code
that sends the connection cookie.
If each user has a different connection cookie, then a packet sniffing
attacker will be able to match up connection cookies to determine whether
or not any given pair of sessions belong to the same user. This may make
traffic analysis easier.
If each user is given a different connection cookie, then a packet
sniffing attacker will be able to identify the first connection attempt
that a new user makes. The attacker my choose to attempt to impersonate
the server in these cases, hoping that the new client doesn't yet have
the server's public host key. The ability to confine such attacks to the
first connection attempts of new users may significantly reduce the risk
of detection.
Anyone see any more disadvantages ?
--
Nick Cleaton
nick at cleaton.net
