Crash when capturing SSL data

This issue was migrated from bug 1796 in our old bug tracker.

Original bug information:

Reporter: Stig Bjørlykke
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: Mac OS X 10.4
Platform: x86
Version: Git

Attachments:

frame-148.pcap: SSL frame which triggers the crash

Stig Bjørlykke said:

Build Information: wireshark 0.99.7 (SVN Rev 22655)

Copyright 1998-2007 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.6.10, with GLib 2.12.0, with libpcap 0.9.4, with libz 1.2.3, with libpcre 4.5, with Net-SNMP 5.2.1, without ADNS, without Lua, with GnuTLS 1.2.11, with Gcrypt 1.2.2, with MIT Kerberos, without PortAudio, without AirPcap.

Running on Darwin 8.10.1, with libpcap version 0.9.4.

Built using gcc 4.0.1 (Apple Computer, Inc. build 5363).

I get a crash when captutring on latest svn (r22655) on OSX.
This happens after some time.  I have mainly HTTP and MDNS traffic, but I don't know which type of package that triggers this.


13:27:36          Err  Per-packet memory corrupted.

Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) where
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x07002c35 in g_logv ()
#4  0x07002cc9 in g_log ()
#5  0x035bb287 in ep_free_all () at emem.c:722
#6  0x035bcad0 in epan_dissect_run (edt=0xacfbfd0, pseudo_header=0xa08826c, data=0x78e6800 "", fd=0xadc0080, cinfo=0x13ed1c) at epan.c:156
#7  0x0000dd6a in add_packet_to_packet_list (fdata=0xadc0080, cf=0x12ec00, dfcode=0x0, pseudo_header=0xa08826c, buf=0x78e6800 "", refilter=1) at file.c:962
#8  0x0000e05f in read_packet (cf=0x12ec00, dfcode=0x0, offset=1398696) at file.c:1095
#9  0x0000e17a in cf_continue_tail (cf=0x12ec00, to_read=11, err=0xbfffe68c) at file.c:657
#10 0x00008901 in capture_input_new_packets (capture_opts=0x13ede0, to_read=21) at capture.c:360
#11 0x0000beaf in sync_pipe_input_cb (source=9, user_data=0x13ede0) at capture_sync.c:1119
#12 0x0001bc77 in pipe_input_cb (data=0x12a97c, source=9, condition=GDK_INPUT_READ) at gui_utils.c:740
#13 0x007222e5 in gdk_io_invoke ()
#14 0x0702a055 in g_io_unix_dispatch ()
#15 0x06ff8eae in g_main_dispatch ()
#16 0x06ffa424 in g_main_context_dispatch ()
#17 0x06ffa9ae in g_main_context_iterate ()
#18 0x06ffb1a3 in g_main_loop_run ()
#19 0x06c69d58 in gtk_main ()
#20 0x0001a385 in main (argc=0, argv=0xbffffbf4) at main.c:3021

added crash osmacos uigtk versiondev labels

Stig Bjørlykke said:

Seems like it's related to SSL, or maybe the new OID functions?

I get this crash when my mail client connects to pop.google.com, and the package which causes the crash contains a certificate.

Part of the certificate looks like this in tshark, and I don't think it's supposed to:

 Item: 1 item (3328483276.2354739301.4244374618.2438267586=Google Inc.)
      Item (3328483276.2354739301.4244374618.2438267586=Google Inc.)
          Id: 2.5.4.10 (id-at-organizationName)
          DirectoryString: printableString (1)
              printableString: Google Inc.

Stig Bjørlykke said:

Created attachment 856 SSL frame which triggers the crash

LEGO said:

Still have to narrow it down it but I guess there's a BO in oid_encoded2subid(). Thanks!

LEGO said:

I checked in a change to initialize to zero the subids array to avoid creating bogus oids, this ceased this crash.

Still I believe the issue is a bigger one in the code that parses the cerificates, it probably assumes somewhere that oid subids are few digits while infact by definition they can be up to infinite (for obvious reasons we have a limit at 0xffffffff).

I'm not closing this bug, until we find that.

LEGO said:

The overflow was in ftype-bytes that calculated a length for the buffer basesd on the length of the encoded oid and oid_encoded2string() was generating a string that was definitevely off.


However due to how oid_repr_len() calculated the oid length there still was a posibility of overflow.

consider the following oid:

77 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f

encoded_length=14
14*3 + 16 = 58 (as oid_repr_len() calculated it)
14*4 + 5 = 61 (the length of the extreme case)

----------------------------------------------------------***
2.39.127.127.127.127.127.127.127.127.127.127.127.127.127.127_
1234567890123456789012345678901234567890123456789012345678901
		 1         2         3         4         5

This would had overflown the buffer by 3 bytes.

closed