This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.

DTLS handshake messages are sent in fragments. Each fragment contains |fragment_offset| and |fragment_length| fields which tell you which parts of the total |length| of message this fragment contains.
https://tools.ietf.org/html/rfc6347#section-4.2.2

Fragments may come in any order and may overlap (senders theoretically can fragment differently as MTU approximations change), so receivers usually maintain a bitmask of how much of the message is available.

I messed up in BoringSSL's implementation and did not correctly handle the case when fragment_offset = fragment_length = length, i.e. we received a zero-length slice just at the end of the message. In that case, and if length is a multiple of 8 (so the bitmask is a whole number of bytes), we would perform a no-op read/write one byte off the end of the bitmask.
https://boringssl.googlesource.com/boringssl/+/b86be3617d4d79db9b418bed78bbf71eadd61f5c/ssl/d1_both.cc#216

Thus an attacker can cause us to perform the equivalent of:

  char *ptr = malloc(N);  // N is an attacker-controlled value between 1 and 12800.
  ptr[N] |= 0;

Our write is a no-op, but we would be unhappy if we manage to race with another thread which is writing there. The only use of DTLS is WebRTC, which is in the sandbox for Chromium.

My sense is this is thus not too worrisome in terms of needing to do anything drastic around the fix, but you all (Chrome security) are the experts. Per out-of-band chat with palmer@, 1-byte overwrites "can be exploitable, but it's usually the topic of a rather heroic blog post". I imagine that it's an overwrite of the existing value adds further constraint here?

The fix is ready (it's all of three lines, plus test), but I have not uploaded it yet since there are other uses of WebRTC and we may wish to patch them privately first? (pthatcher, thoughts?)

The was found by libFuzzer and the new DTLS fuzzers I put together yesterday. I'll upload those once the fix is public. (Yay libFuzzer!)

VERSION
Chrome Version: [x.x.x.x] + [stable, beta, or dev]
Operating System: all

REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab, browser, etc.]
Crash State: [see link above: stack trace, registers, exception record]
Client ID (if relevant): [see link above]