CVE-2010-3445: Wireshark ASN.1 BER Stack Overflow

This vulnerability was discovered by The Penetration Test Team of NCNIPC as we can read in the official security advisory and it affects Wireshark 1.2 up to (and including) 1.2.11 and 1.4.0. The bug was reported on 13 September 2010 at the BugTraq mailing list as you can see here.
Here is the susceptible function which is available at epan/dissectors/packet-ber.c

This function is called when an unknown ASN.1 BER encoded content is encountered in a packet. The Penetration Test Team of NCNIPC triggered this through an SNMPv1 packet’s variable bindings item. Back to dissect_unknown_ber()’s code we can read the following…

So, in case of a message with no constructor flag set, it will fall into the above ‘switch’ statement. If this is has a class of ‘BER_UNI_TAG_OCTETSTRING’ it will enter this case. In this code, if it’s able to detect a possible BER encoded data section and ‘show_internal_ber_fields’ allows it, it will recursively invoke dissect_unknown_ber().
A similar recursion also appears in the case of a set constructor flag as you can read here:

The bug here is that a malicious user can construct a packet with an unknown ASN.1/BER encoded message in order to trigger this recursion. For example, if the variable bindings’ item in the SNMP PDU is set to some huge value, this function will be recursively invoked so many times that it’ll eventually consume so much stack memory’s space that will lead to a stack overflow.
In order to fix this, Wireshark’s developers developed and applied the following patch…

+/*
+ * Set a limit on recursion so we don't blow away the stack. Another approach
+ * would be to remove recursion completely but then we'd exhaust CPU+memory
+ * trying to read a hellabyte of nested indefinite lengths.
+ * XXX - Max nesting in the ASN.1 plugin is 32. Should they match?
+ */
+#define BER_MAX_NESTING 500
+

So, the comment is pretty clear here. I won’t add anything else. Also, the buggy routine dissect_unknown_ber() was renamed and a new argument was added…

The old constant ‘BER_MAX_INDEFINITE_NESTING’ was removed since the new ‘BER_MAX_NESTING’ is used now…

-/*
- * Set a limit on recursion so we don't blow away the stack. Another approach
- * would be to remove recursion completely but then we'd exhaust CPU+memory
- * trying to read a hellabyte of nested indefinite lengths.
- * XXX - Max nesting in the ASN.1 plugin is 32. Should they match?
- */
-#define BER_MAX_INDEFINITE_NESTING 500

In the Wireshark Bug Database we can also find a PCAP capture file that can be used to trigger the vulnerability. You can download ‘ber_unknown_overflow.pcap’ here. You can make a DoS exploit code pretty fast using this capture file. Here is a more detailed representation of its contents (from the UDP datagram and below)…

This item in variable bindings of the packet is simply a sequence of the following data:

0x30, 0x82, 0x2e, 0xe4, 0x06, 0x00
"a" x 12000

Wireshark recognizes the initial sequence of bytes as primitive encoded value with sequence OID of 3158140172 (which is also indicated as a malformed OID). Then, it will continue having nested applications as far as your stack can hold :P