COMMAND
SSH
SYSTEMS AFFECTED
Systems running SSH using protocol 1.x
PROBLEM
Following info is based on CORE SDI S.A. Security Advisory on SSH
insertion attack. SSH (Secure Shell) is a program that provides
strong authentication and secure communications over insecure
channels. Its widely used for logging in to remote computers,
file transfers and tunneling of other protocols over the encrypted
comunications channel. All communications are automatically and
transparently encrypted. Encryption is also used for integrity
checking purposes although current implementations rely on a 32
bit Cyclic Redundancy Check to perform integrity checks after the
decryption of an incoming packet.
Encryption is done using one of a list of supported algorithms
that is exchanged between client and server. Upon conection
establishment client and server perform a protocol negotiation
that includes mutual authentication, selection of a cipher
supported by both ends for subsequent communications and of a
session key to be used with the cipher. Encryption is then turned
on using the selected cipher and session key, all further
communications are encrypted. Currently supported ciphers are:
- Blowfish
Bruce Schneier's block cipher using a 128 bit key
- IDEA
A 128 bit block cipher
- DES
The Data Encryption Standard 56-bit block cipher
- Triple DES (3DES)
A three-key triple-DES algorithm with an effective key
lenght of 112 bits.
- ARCFOUR
An RC4 compatible stream cipher using a 128 bit key
The use of these algorithms in CBC (Cipher Block Chaining) or CFB
(Cipher Feedback 64 bits) modes with the CRC-32 integrity check
allows to perform a known plaintext attack (with as few as
16 bytes of known plaintext) that permits the insertion of
encrypted packets with any choosen plaintext in the client to
server stream that will subvert the integrity checks on the server
and decrypt to the given plaintext, thus allowing an attacker
to execute arbitrary commands on the server. The attack is
equally feasible on the server to client stream , although it
just gives the ability to send arbitrary data the user's terminal.
The implications of such an attack are probably not as severe as
an attack to the server side of the connection but must be taken
in consideration in the process of applying fixes.
After the protocol identification phase, where the server sends a
plaintext string specifiying its the protocol and software
versions, all communication is done encapsulating data in a
packet format described as 'The Binary Packet Protocol'. The
packet layout is as follows:
32 24 16 8 0
+----------+---------+---------+---------+
| data length (bytes) |
+----------+---------+---------+---------+
| 1 to 8 bytes of padding |
= =
+----------+---------+---------+---------+
| type | |
+----------+ +
| |
= data =
| |
+----------+---------+---------+---------+
| CRC-32 |
+----------+---------+---------+---------+
Data length: Length in bytes of the given packet, not including
the length field and padding
Padding : 8 - (length mod 8) bytes of random data, putting
random data at the beginning of the packet is an
effort to make known plaintext attacks more difficult.
Packet type: An 8-bit unsigned byte.
Data : length - 5 data bytes
CRC-32 : the four 8-bit check bytes, MSB first. The CRC is
computed before any encryption
Encryption is done on the padding+type+data+CRC fields, the length
field is never encrypted. The encrypted portion of the packet has
a length that is always a multiple of 8 bytes. Knowning certain
characteristics of the cipher modes being used, i.e. CBC, with a
known plaintext an attacker is able to build a custom SSH packet
(i.e. a type SSH_CMSG_STDIN_DATA packet) with the padding bytes
computed in a way such that the next 8-bytes of the encrypted data
will decrypt to arbitrary plaintext. In this particular case,
the decrypted data will correspond to the type field and 7 data
bytes. After the 16 bytes (padding+type+7 data bytes) the
attacker would include a variable length of data bytes
specifically crafted to produce a valid CRC-32 field for the
whole packet once it is decrypted. This attack and several
variations using the same technique can be performed due to the
usage of weak integrity check schemes, in particular CRC-32 has
certain properties that allows the attacker to forge a valid CRC
for her corrupted packet. However, for the attack to succeed the
attacker must be able to perform an active network attack, by
either intercepting the legit SSH connection at any point between
the client and server and injecting a forged packet or by
performing a TCP session hijack attack.
SOLUTION
Upgrade to the upcoming SSH protocol version 2. Commercial
F-Secure SSH users contact Data Fellows Inc. for information on
how to upgrade to F-Secure 2.0. Notice that version 2 of the SSH
protocol is not compatible with the previous version, thus you
will need to upgrade all the SSH clients as well. In the
meantime, upgrade to version 1.2.25 of SSH, which fixes the
problem. The SSH 1.2.25 distribution can be obtained from:
ftp://ftp.cs.hut.fi/pub/ssh/ssh-1.2.25.tar.gz
F-Secure SSH version 1.3.5 fixes this security problem. If you
are using the commercial Data Fellows SSH package and you have a
support contract, you can obtain the 1.3.5 from your local
retailer. Users without a support contract can obtain a patch
which fixes this problem from:
http://www.DataFellows.com/f-secure/support/ssh/bug/su134patch.html
A patch for the free SSH 1.2.23 distribution and the complete SSH
1.2.23 package, with the patch applied, can be obtained at:
http://www.core-sdi.com/ssh
This patch was updated somewhere around 6th July. Patches apply
to the original SSH distributions 1.2.23 and 1.2.25