160207 - SSL/TLS attack on block cipher padding in CBC mode

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

In http://www.openssl.org/~bodo/tls-cbc.txt the author describes an 
attack, attributed to Serge Vaudenay, against SSL/TLS ciphersuites 
that use block ciphers and CBC mode.

To safeguard against this attack, he recommends that TLS and SSL3 
implementations always return the alert bad_record_mac whenever the 
value of a padding byte does not contain the expected result.  
He recommends that the TLS alert decryption_failed be sent only 
when the input is not a multiple of the block size.

This attack is against the symmetric cipher keys in a session, not
against the server's private key(s).  
This attack has been public for some time.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch makes recommended changes (checked into NSS 3.6)

Review invited.

Comment 2

[Wan-Teh Chang]

Comment on attachment 93348 [details] [diff] [review]
patch makes recommended changes (checked into NSS 3.6)

r=wtc.

Nelson told me that the first change in this patch
is really an unrelated bug fix (the bug is that we
are not sending any alert if the protocol is SSL3).

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

patch checked in

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I'm reopening this bug.  The patch checked in last August, which implemented
changes recommended in the paper cited above, does NOT eliminate the 
vulnerability it was intended to prevent.  Consequently, servers based 
on NSS 3.6 are still vulnerable to this attack, despite those changes.

The attack depends on the ability to differentiate among various errors 
that may occur when processing a received encrypted TLS record.  The cited
paper recommended using the same error code in the alert records (TLS error 
messages) for all these errors, making it impossible to differentiate among 
the errors by the error code values.  That is what the patch from last August
did.  But the error codes may never have been very useful to an attacker,
because they are encrypted.  The attacker used other means than error codes
to differentiate among the errors, So, eliminating differences in error codes 
alone is insufficient to eliminate the vulnerability.  

http://lasecwww.epfl.ch/memo_ssl.shtml reveals the use of timing of the
error messages, rather than their content (which is encrypted) to 
differentiate among the types of errors.  Servers may choose to skip the 
CPU-intensive MAC calculation when the results of a previous test make
it obvious that the MAC result will be incorrect prior to computing it.  
But consequently, the server's error message is sent more quickly than if 
the MAC was computed in all cases.  The attacker uses the server's time 
savings to his advantage.

Below I will attach a new patch that, when applied to the present NSS
trunk sources, will render that timing attack ineffective by computing a
MAC on received records whenever feasible, even when the TLS padding 
value is obviously incorrect.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Changing target milestone to NSS 3.8.  Perhaps this should go into 3.7.2?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: new patch, v1

This patch is to be applied on top of the code with the previous patch.
It is not a replacement for the previous patch, but suplements that patch.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Adding Terry to cc list.  

Terry, please review comments and patch recently added to this bug.

Comment 8

[Wan-Teh Chang]

Ian, could you review Nelson's new patch (attachment 115133 [details] [diff] [review])?

Comment 9

[Ian McGreer]

Comment on attachment 115133 [details] [diff] [review]
new patch, v1


This looks correct to me.  r=mcgreer

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Here's a slightly better explanation than the one I gave in comment 4 above.

The attacker observes an existing TLS connection that has completed a TLS
handshake and has sent a message from client to server that contains the 
client's password.  The attacker then constructs a specially designed TLS
record and sends it to the server, making it appear to have come from the 
client.  The constructed record is likely to cause the server to encounter
an error when the server decrypts it and attempts to validate it.  

The attack depends on the attacker's ability to determine which of the 
various errors is detected by the server when processing that special TLS
record.  There are potentially several different ways that the attacker might
make this determination.  

If the server sends out different error messages for the different errors, 
the attacker MIGHT be able to use those different error messages to determine
which error occurred.  The cited paper recommended having the server send out 
a single error code regardless of which of the different errors occured while
validating the decrypted record.  That would make it impossible for the 
attacker to use the error code number from the server to determine which 
error occurred.  But in practice, the error codes are probably not very useful 
to the attacker because they are encrypted and the attacker typically cannot
decrypt them.  The attacker has to use other means to determine which error
occured.  So making the server send a single error code doesn't actually thwart
the attack.  

I must correct one statement in my original description of the attack,
preceeding comment 1 above.  This is not an attack on keys.  It is an attack
that reveals the plain text of the messages without determining any keys.

I have another, better, patch forthcoming.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

What should users of existing NSS-based client and server products do in 
response to this bug?

In my opinion, client users do not need to take any action.  If they wish, they
can disable TLS (but not SSL3) in the security preferences in mozilla or
Netscape browsers, as an additional protection for unfixed servers.

In my opinion, administrators of servers that implement TLS should disable TLS
(not SSL3) until they can get a fixed version of the server.  Administrators of
servers that do NOT implement TLS do not need to take any action, in my opinion.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch v2, incorporating review feedback from wtc and thayes

This patch computes a MAC in ALL cases, unless the decryption fails completely
or the MAC computation fails.  Also, better comments.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Note, the paper that explains the actual attack is found at
http://lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps

Patch v2 checked in on trunk, after receiving oral review approval from 
wtc and thayes.  Thanks also to Ian for reviewing patch v1.

Comment 14

[Wan-Teh Chang]

Comment on attachment 115181 [details] [diff] [review]
patch v2, incorporating review feedback from wtc and thayes

r=wtc.

Comment 15

[Wan-Teh Chang]

Comment on attachment 115181 [details] [diff] [review]
patch v2, incorporating review feedback from wtc and thayes

Requesting mozilla 1.3 approval.

Comment 16

[Terry Hayes]

Comment on attachment 115181 [details] [diff] [review]
patch v2, incorporating review feedback from wtc and thayes

sr=thayes

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 115181 [details] [diff] [review]
patch v2, incorporating review feedback from wtc and thayes

Approving for mozilla 1.3 (which should now be on the MOZILLA_1_3_BRANCH).

Comment 18

[Wan-Teh Chang]

Comment on attachment 115181 [details] [diff] [review]
patch v2, incorporating review feedback from wtc and thayes

Patch checked into NSS_CLIENT_TAG for the Mozilla trunk (1.4alpha).

Comment 19

[Wan-Teh Chang]

Patch checked into the NSS_3_7_BRANCH for the NSS 3.7.2 release.

Comment 20

[Wan-Teh Chang]

Comment on attachment 115181 [details] [diff] [review]
patch v2, incorporating review feedback from wtc and thayes

I checked in this patch on the MOZILLA_1_3_BRANCH for mozilla 1.3 final.

Comment 21

[Ian McGreer]

patch checked into NSS_3_3_BRANCH.

Checking in ssl3con.c;
/cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v  <--  ssl3con.c
new revision: 1.21.2.3; previous revision: 1.21.2.2
done

Comment 22

[Wan-Teh Chang]

Patch checked into NSS_3_4_BRANCH (ssl3con.c, rev. 1.35.8.1).