More Details Regarding CVE-2014-0195 (DTLS arbitrary code execution)

Published: 2014-06-05
Last Updated: 2014-06-05 21:17:09 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

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

Keywords: openssl
1 comment(s)

Comments

This CVE may provide a possible avenue for remote exploitation of Cisco ASA firewalls.

Have read that ASA firmware incorporates OpenSSL 0.9.8.

The "Anyconnect" SSL VPN supports both TLS and DTLS
and it is conceivable that ASAs configured with
Anyconnect might be remotely exploited via this
flaw. DTLS is enabled by default when Anyconnect
is turned on.

Cisco say they are "investigating":

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140605-openssl

http://tools.cisco.com/security/center/viewAlert.x?alertId=34546

An unauthenticated, remote attacker
could exploit this vulnerability by
sending DTLS fragments to a targeted
system. A successful exploit could cause
a buffer overrun condition that the
attacker could use to execute arbitrary
code on the system. If OpenSSL is
running with elevated privileges on the
system, exploitation could result in a
complete system compromise.

Until more is known, prudent admins should
disable DTLS thusly

configure terminal
webvpn
enable outside tls-only # one per active if
exit
exit
reload save-config noconfirm

and then verify their firmware image
has not been modified for good measure.

Diary Archives