1

Plaintext Recovery Attacks Against SSH

Kenny Paterson

Information Security Group

Royal Holloway, University of London

kenny.paterson@rhul.ac.uk

Joint work with Martin Albrecht and Gaven Watson

2

CINS/F1-01

Status of this talk

• The results of this talk are unpublished but submitted for publication.

• A security advisory was issued to the public through the UK Centre for the Protection of National Infrastructure (CPNI-957037, CVE-2008-5161).

• From the advisory and subsequent vendor patches it would be fairly easy to reverse engineer the attack.

3

CINS/F1-01

SSH

Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for TELNET and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.

– Wikipedia

4

CINS/F1-01

SSH

• SSHv1 had several security flaws.• SSHv2 was standardised in 2006 by the IETF in RFCs

4251-4254.• RFC 4253 specifies the SSH Binary Packet Protocol

(BPP).– Symmetric encryption and integrity protection for SSH packets,

using keys agreed in an earlier exchange.

• SSHv2 is widely regarded as being very secure.– Notwithstanding a minor flaw in the BPP that allows

distinguishing attacks (Dai, Bellare et al.).

• Simple variants of the SSH BPP were proven secure by Bellare et al. using the “provable security” approach.– Key example: SSH using randomised padding and CBC mode

encryption with explicit IVs.

5

CINS/F1-01

The SSH BPP

• Encode-then-Encrypt&MAC construction.

• Sequence number is not sent on the wire.

• Packet length is encrypted to hide true length of SSH packets on the wire.

• RFC mandates 3DES-CBC and recommends AES-CBC.– In fact, all originally specified optional configurations involve CBC mode, and

ARCFOUR is the only optional stream cipher.

6

CBC mode encryption

• SSH uses a chained IV in CBC mode– IV for this packet is the last ciphertext block from the previous packet.– Effectively creates a single stream of data from multiple SSH packets.

7

CBC mode decryption

8

The basis for an attack

Our attack is possible due to an interaction of the following BPP features:

• The packet length field encodes how much data needs to be received before the MAC should be checked. Thus this field must be decrypted before the MAC is checked;

• The attacker can send data on an SSH connection in small chunks (TCP);

• CBC mode is mandated;• A MAC failure is visible on the network.

9

The attack

• The attacker intercepts a target ciphertext block from the SSH connection.

• The attacker sends the target block as the first block of a new SSH packet on the connection.– The recipient will treat the first 32 bits of that block

as the packet length field.

• The attacker then feeds random ciphertext blocks into the SSH connection.– One block at a time, waiting to see what happens

with each new block.

10

The attack

• Once enough data has arrived, the recipient checks the MAC.– This check will fail with overwhelming probability.– Consequently the connection is terminated with an

error message.– The number of random blocks required to trigger the

error message reveals the content of the 32-bit packet length field.

– Because of CBC mode, this in turn reveals 32 bits of the target plaintext block.

• Needs some simple XOR arithmetic to account for effect of changing the chaining variable.

11

Performance of the attack

• As described, the attack would succeed with probability 1, but would require the injection of around 227 random blocks.

• In practice, various sanity checks on the length field are performed by implementations….

12

Performance of the attack

According to RFC 4253:

• “Note that the `packet_length' field is also encrypted, and processing it requires special care when sending or receiving packets.”

• “The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus `mac'). Implementations SHOULD decrypt the length after receiving the first 8 (or cipher block size, whichever is larger) bytes of a packet.”

• “… implementations SHOULD check that the packet length is reasonable in order for the implementation to avoid denial of service and/or buffer overflow attacks.”

13

OpenSSH

• In the OpenSSH implementation, two sanity checks are carried out.

• When each of the checks fails, the SSH connection is terminated in subtly different ways.

• This allows:– A first attack verifiably recovering 14 bits of plaintext with

probability 2-14.– A second attack verifiably recovering 32 bits of plaintext with

probability 2-18 (for a 128-bit block cipher).

• Both attacks result in termination of the SSH connection with high probability.

• We implemented the attacks against OpenSSH 4.7 – and they work.

14

Two remarks

• If a plaintext is repeated at a fixed position in SSH packets over multiple connections, then the attack can be iterated to boost success rate.– Application to password extraction.– Some clients automatically reconnect on session

termination.

• The attack applies even if a fresh random IV is used for each packet.– Assuming this is sent in clear on the connection.– The iterated attack becomes more effective.

15

Vendor reactions

• OpenSSH published a statement and committed a first fix. – See www.openssh.com/txt/cbc.adv– Both the statement and the bugfix only address the probability 2-14

OpenSSH specific attack.

• SunSSH increased the version number because of a security vulnerability ``for the first time''. – However, it seems they only fixed the 2-14 attack.

• SSH.com acknowledged that their products are vulnerable and claim to have addressed the issue.

• WinSSHD acknowledged that their product is vulnerable and issued an update which successfully prevents the attack.

• Dropbear added counter mode cipher support, which avoids some security problems with the standard CBC mode.

• …

16

Work-arounds

• Use counter mode.– Configurable, some implementations currently only support

ARC4).– Stateful version required to prevent attacker exploiting

keystream repeats.

• Enforce use of counter mode.– Not standards compliant with RFCs as currently written.

• Randomise the length field if length check fails.– Tricky to implement.

• Don't encrypt the length field.– Invasive and makes certain DoS attacks easier.

• Redesign BPP to use authenticated encryption with associated data (AEAD) algorithm.– Invasive, and still can’t safely encrypt length field.

17

Comparison with proven security

• Recall that Bellare et al. proved that variants of the SSH BPP are provably secure.– In particular, SSH-$NPC, i.e. randomised, per-

packet IV with random padding field.– Our attacks apply to this variant.

• So what went wrong?

18

Comparison with proven security

• The security model of Bellare et al. does model errors during the BPP decryption process.– Connection teardown is modeled by disallowing

access to decryption and encryption oracles after any error event.

– Only a single type of error message is output.– Our 2-14 attack against OpenSSH exploits the fact

that the errors are distinguishable.– But even allowing only one error type, there is a very

simple distinguishing attack having probability 1 against SSH-$NPC!

19

Comparison with proven security

• Security model of Bellare et al. assumes that ciphertexts are “self-describing” in terms of length.– Ciphertexts and plaintexts are handled in the model

as “atomic” strings.– The model does not allow for the possibility that the

amount of data needed to complete the decryption process might be governed by data that is produced during the decryption process itself.

– Indeed, after an initial description of the BPP packet format, the length field never appears again in their analysis!

20

Limitations of provable security

• Our attack on SSH illustrates some of the limitations of current approaches to provable security.

• How do we know what system features should be included in a security model?– What is the right amount of abstraction?– How close to the implementation level do we need to go to

capture all significant attack vectors?• c.f. Attack against SSL/TLS by Canvel et al. versus Krawczyk’s

security proof for SSL/TLS Record Layer.

– How high do we need to go to handle interactions between low-level cryptography and the overall system?

• c.f. Attacks against IPsec exploiting error messages carried by an upper layer protocol (ICMP) (P. and Yau, Degabriele and P.)

21

Future directions

• Can we extend current security models for protocols to handle “implementation” issues such as data formats, error processing and side channels?– What about accurate modeling for SSH?– See P. and Watson (SCN 2008) for an example of

how to provably immunize CBC mode encryption against the special class of Padding Oracle attacks.

– Is there a general theoretical approach which shows how to securely handle error messages?

22

A closing quote

From Bellare et al.:…in the modern era of strong cryptography it

would seem counterintuitive to voluntarily use a protocol with low security when it is possible to fix the security of SSH at low cost.

• Provable security is one of the best tools we currently have.

• But how do we know that “fixing” SSH actually improves security?– Our attack applies equally to current BPP and to

provably secure SSH-$NPC.