1328122 - (CVE-2017-7502) Various ssl3_GatherData() issues

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

The fuzzing target's implementation of `recv` showed that ssl_DefRecv() can be called with buf=NULL _and_ len=0. While this isn't too bad assuming that the underlying `recv` implementation can handle it, it probably would be nice to avoid those calls. There however are a few other issues, esp. with the v2 ClientHello handling code.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

When we receive an empty v2 record, i.e. in long form = {0x00, 0x00, 0x00, 0x00, x00}, where the last 2 bytes are appended because ssl3_GatherData() expects 5 bytes total, then we try to memcpy() into `gs->inbuf`. The problem is that `gs->inbuf.buf` is still NULL and so we have a NULL dereference. After that we set `gs->remainder` to -2 or -3 and call ssl_DefRecv() that will usually err out with PR_BUFFER_OVERFLOW_ERROR. But that also is dependent on the actual implementation of `recv`.

Assigning sec-moderate, memcpy(NULL, _) seems hard to exploit, only in rare situations and environments. Also this only affects NSS servers.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

https://nss-review.dev.mozaws.net/D135

Comment 3

[Martin Thomson [:mt:]]

The fix you have looks fine, though I would observe that removing support for v2-compatible ClientHello would be a much neater change.  Maybe we can put that on the executioners block this year.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Indeed. I really don't want to support it... but we probably have to keep it for now. Until RedHat agrees to remove it.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/projects/nss/rev/55ea60effd0d

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/projects/nss/rev/fe14434b5996

Comment 7

[Kai Engert (:KaiE:)]

Thanks for fixing the v2 code, yes Red Hat still needs it for compatibility.

Comment 8

[Huzaifa Sidhpurwala]

Is mozilla going to assign a cve to this issue, or we should?

Comment 9

[Huzaifa Sidhpurwala]

We have assigned CVE-2017-7502 to this issue.