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 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 4113 Posts ISC Handler Jun 5th 2014 |
Thread locked Subscribe |
Jun 5th 2014 6 years ago |
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. |
Anonymous |
Quote |
Jun 6th 2014 6 years ago |
Sign Up for Free or Log In to start participating in the conversation!