1272750 - Crash in ssl3_SetupPendingCipherSpec | ssl3_HandleServerHelloPart2 | ssl3_HandleServerHello | ssl3_HandleHandshakeMessage | ssl3_HandleHandshake | ssl3_HandleRecord | ssl3_GatherCompleteHandshake | ssl_GatherRecord1stHandshake | ssl_Do1stHandshake | ss...

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Andrew McCreight [:mccr8]]

This bug was filed from the Socorro interface and is 
report bp-aee086f2-8176-44f3-be9f-d0f512160513.
=============================================================

Number 8 Windows Nightly crash on 5-11, though it appears to be a single user, judging by install time. No URLs besides about:blank, and no addon, so I'm not sure what is going on. I'm also not sure why the signature is so long.

Comment 1

[Eric Rescorla (:ekr)]

ttaubert, any chance you could take a look

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Hard to tell what's going on here without more data or a way to reproduce. It looks like indeed all the crash reports come from a single user. It's crashing at line 1565:

> 1563  mac = suite_def->mac_alg;
> 1564  if (mac <= ssl_mac_sha && mac != ssl_mac_null && isTLS)
> 1565      mac += 2;

https://hg.mozilla.org/mozilla-central/annotate/674a55274378/security/nss/lib/ssl/ssl3con.c#l1565

I think it shouldn't be possible to crash here. Is it likely that the affected user has faulty HW? Not sure though if that could crash Firefox twelve times with the same signature.

Comment 3

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

khuey and I looked at this.  In particular, minidump bp-aee086f2-8176-44f3-be9f-d0f512160513

There's a single bit flip in the binary.  Given that it's happening repeatedly, it's presumably a bit flip on disk rather than a bit flip in RAM.

The disassembly of:

    if (mac <= ssl_mac_sha && mac != ssl_mac_null && isTLS)
        mac += 2;

(plus one instruction following it) is supposed to be (if I download the binary and objdump -Cd nss3.dll):

   180110252:   41 83 f8 02             cmp    $0x2,%r8d
   180110256:   7f 0d                   jg     0x180110265
   180110258:   45 85 c0                test   %r8d,%r8d
   18011025b:   74 08                   je     0x180110265
   18011025d:   85 f6                   test   %esi,%esi
   18011025f:   74 04                   je     0x180110265
   180110261:   41 83 c0 02             add    $0x2,%r8d
   180110265:   48 89 83 80 04 00 00    mov    %rax,0x480(%rbx)

however, in the second to last instruction, the user has the 83 bit-flipped to 8b, which transforms the last 2 instructions (well, not all of the second of those instructions) into:

   180110261:   41 8b c0                mov    %r8d,%eax
   180110264:   02 48 89                add    -0x77(%rax),%cl

so we crash with EIP at 0x180110264.

Comment 4

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

(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #3)
> There's a single bit flip in the binary.  Given that it's happening
> repeatedly, it's presumably a bit flip on disk rather than a bit flip in RAM.

(Although if they're close together in time I guess that's not necessarily true.)

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

Great investigation, thank you David and Kyle!