xorl %eax, %eax

CVE-2009-0599: Wireshark NetScreen Stack Overflow

leave a comment »

Wireshark really surprises me. I just had a quick look at this bug it it surprisingly straightforward. Anyway, it was reported by babi on 19 December 2008 and affects Wireshark up to 1.0.5 release. The following code is of course from Wireshark 1.0.5 release. This bug is located at the Juniper NetScreen snoop parser that Wireshark has at wiretap/netscreen.c. The vulnerability is at this function (which has an amazingly detailed comment which I would like to share with you):

314 /* Parses a packet record header. There are a few possible formats:
315  *
316  * XXX list extra formats here!
317 6843828.0: trust(o) len=98:00121ebbd132->00600868d659/0800
318               192.168.1.1 -> 192.168.1.10/6
319               vhl=45, tos=00, id=37739, frag=0000, ttl=64 tlen=84
320               tcp:ports 2222->2333, seq=3452113890, ack=1540618280, flag=5018/ACK
321               00 60 08 68 d6 59 00 12 1e bb d1 32 08 00 45 00     .`.h.Y.....2..E.
322               00 54 93 6b 00 00 40 06 63 dd c0 a8 01 01 c0 a8     .T.k..@.c.......
323               01 0a 08 ae 09 1d cd c3 13 e2 5b d3 f8 28 50 18     ..........[..(P.
324               1f d4 79 21 00 00 e7 76 89 64 16 e2 19 0a 80 09     ..y!...v.d......
325               31 e7 04 28 04 58 f3 d9 b1 9f 3d 65 1a db d8 61     1..(.X....=e...a
326               2c 21 b6 d3 20 60 0c 8c 35 98 88 cf 20 91 0e a9     ,!...`..5.......
327               1d 0b                                               ..
328
329
330  */
331 static int
332 parse_netscreen_rec_hdr(wtap *wth, const char *line, char *cap_int, gboolean *cap_dir,
333     union wtap_pseudo_header *pseudo_header _U_, int *err, gchar **err_info)
334 {
       ...
339         if (sscanf(line, "%d.%d: %[a-z0-9/:.](%[io]) len=%d:",
340                    &sec, &dsec, cap_int, direction, &pkt_len) != 5) {
341                 *err = WTAP_ERR_BAD_RECORD;
342                 *err_info = g_strdup("netscreen: Can't parse packet-header");
343                 return -1;
344         }
       ...
354         return pkt_len;
355 }

Alright, I’m sure that most of you got it that there should be something wrong with the sscanf() at line 339. But let’s take a closer look:

%d            = &sec
%d            = &dsec
%[a-z0-9/:.]  = cap_int
%[io]         = direction
%d            = &pkt_len

Do you see it now? cap_int which is a char * as well as direction which is a two bytes long character array can overflow since the above format do not provide any limitations on string length. This patch was fairly simple:

     char    direction[2];

+    if (sscanf(line, "%d.%d: %15[a-z0-9/:.](%1[io]) len=%d:",
            &sec, &dsec, cap_int, direction, &pkt_len) != 5) {
-    if (sscanf(line, "%d.%d: %[a-z0-9/:.](%[io]) len=%d:",
         *err = WTAP_ERR_BAD_RECORD;

So.. that’s all with this bug. Now load up your packet generators to trigger this :P
Well, it is kind of funny that many vulnerability databases on the interwebs classified this bug as denial of service. I think that the approach of classifying any memory corruption vulnerability as possible code execution is more effective since you’ll be prepared for something like this appropriately. Anyway…

Written by xorl

March 12, 2009 at 14:38

Posted in bugs

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