SSL/TLS attack on block cipher padding in CBC mode

RESOLVED FIXED in 3.7.2

Status

NSS
Libraries
P1
major
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [3.4.3] fixed1.3, URL)

Attachments

(2 attachments, 1 obsolete attachment)

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.
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 3.6
(Assignee)

Comment 1

15 years ago
Created attachment 93348 [details] [diff] [review]
patch makes recommended changes (checked into NSS 3.6)

Review invited.

Comment 2

15 years ago
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).
Attachment #93348 - Flags: review+
(Assignee)

Comment 3

15 years ago
patch checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

15 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 5

15 years ago
Changing target milestone to NSS 3.8.  Perhaps this should go into 3.7.2?
Severity: normal → major
Target Milestone: 3.6 → 3.8
(Assignee)

Comment 6

15 years ago
Created attachment 115133 [details] [diff] [review]
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.
(Assignee)

Updated

15 years ago
Attachment #115133 - Flags: superreview?(wtc)
Attachment #115133 - Flags: review?(thayes)
(Assignee)

Comment 7

15 years ago
Adding Terry to cc list.  

Terry, please review comments and patch recently added to this bug.
Status: REOPENED → ASSIGNED

Comment 8

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

Updated

15 years ago
Attachment #93348 - Attachment description: patch makes recommended changes → patch makes recommended changes (checked into NSS 3.6)

Comment 9

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


This looks correct to me.  r=mcgreer
(Assignee)

Comment 10

15 years ago
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.
(Assignee)

Comment 11

15 years ago
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.
(Assignee)

Comment 12

15 years ago
Created attachment 115181 [details] [diff] [review]
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.
Attachment #115133 - Attachment is obsolete: true
(Assignee)

Comment 13

15 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 14

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

r=wtc.
Attachment #115181 - Flags: superreview?(thayes)
Attachment #115181 - Flags: review+

Updated

15 years ago
Attachment #115181 - Flags: superreview?(thayes) → superreview+

Comment 15

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

Requesting mozilla 1.3 approval.
Attachment #115181 - Flags: approval1.3?

Comment 16

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

sr=thayes

Updated

15 years ago
Attachment #115133 - Flags: superreview?(wtc)
Attachment #115133 - Flags: review?(thayes)
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).
Attachment #115181 - Flags: approval1.3? → approval1.3+

Comment 18

15 years ago
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

15 years ago
Patch checked into the NSS_3_7_BRANCH for the NSS 3.7.2 release.
Target Milestone: 3.8 → 3.7.2

Comment 20

15 years ago
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

15 years ago
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

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

Updated

15 years ago
Whiteboard: [3.4.3]

Updated

15 years ago
Whiteboard: [3.4.3] → [3.4.3] fixed1.3
You need to log in before you can comment on or make changes to this bug.