HP's Zero Day Initiative released a few more details about this bug explaining the nature of the problem. It is actually remarkably similar to some of the IP fragmentation bug we have see in the past.

DTLS attempts to avoid IP fragmentation. But many SSL related messages contain data (for example certificates) that exceed common network MTUs. As a result, DTLS fragments the messages. Each message fragment contains 3 length related fields:

- Message size (Length) - this is the total size after reassembly. Should be same for all fragments 
- Fragment Offset - where does this fragment fit in the original message.
- Fragment Length - how much data does this fragment contain.

If there is no fragmentation, the fragment length is equal to the message size. However, if the fragment length is less then the message size, we do have fragmentation. Each fragment should indicate the same message size.

This is different from IP. In IP, the fragment does not know how large the original package was, and we use the "more fragment" flag to figure out when all fragments are received.

Once OpenSSL receives a fragment, it allocates "Length" bytes to reassemble the entire message. However, the trick is that the next fragment may actually indicate a larger message size, and as a result, deliver more data then OpenSSL reserved, leading to a typical buffer overflow.

You can see the complete source code at HP's blog, including a Wireshark display of a PoC packet. This essentially provides a PoC for this vulnerability. Interestingly Wireshark does recognize this as an error.

[1] http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/ZDI-14-173-CVE-2014-0195-OpenSSL-DTLS-Fragment-Out-of-Bounds/ba-p/6501002#.U5C78BYXk2-

(this is different, but sort of reminds me of the OpenBSD mbuf problem in IPv6, CVE-2007-1365)

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn