Wireshark-bugs: [Wireshark-bugs] [Bug 11417] New: SOCKS decoder giving strange values for seemin
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 04 Aug 2015 22:43:39 +0000
Bug ID 11417
Summary SOCKS decoder giving strange values for seemingly normal SOCKS connection, parser bug?
Product Wireshark
Version 1.12.6
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Major
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter 8libra@gmail.com 

Created attachment 13771 [details]
Example SOCKS connection that seems to trip up the parser

Build Information:
TShark 1.12.6 (v1.12.6-0-gee1fce6 from master-1.12)

Copyright 1998-2015 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 (64-bit) with GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with
SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15,
with Gcrypt 1.6.2, without Kerberos, with GeoIP.

Running on 64-bit Windows 7 Service Pack 1, build 7601, without WinPcap.
       Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz, with 8035MB of physical
memory.


Built using Microsoft Visual C++ 10.0 build 40219

--
Hello, I'm analyzing a lot of SOCKS 5 proxy traffic, and a significant quanity
is not decoding correctly. The example I'm attaching has no missing packets or
bytes in the bytestream, and has valid/normal values in the SOCKS protocol.
Maybe its TCP options throwing off the parser? I'm stumped.


$ tshark -r socks_example.pcap -d tcp.port==24042
  1   0.000000 176.9.19.103 -> 172.31.15.199 TCP 74 41492→24042 [SYN] Seq=0
Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=721658576 TSecr=0 WS=128
  2   0.000022 172.31.15.199 -> 176.9.19.103 TCP 74 24042→41492 [SYN, ACK]
Seq=0 Ack=1 Win=26847 Len=0 MSS=8961 SACK_PERM=1 TSval=506027890
TSecr=721658576 WS=128
  3   0.096901 176.9.19.103 -> 172.31.15.199 TCP 66 41492→24042 [ACK] Seq=1
Ack=1 Win=29312 Len=0 TSval=721658600 TSecr=506027890
  4   0.096951 176.9.19.103 -> 172.31.15.199 Socks 70 Version: 5 Connect to
server request
  5   0.096958 172.31.15.199 -> 176.9.19.103 TCP 66 24042→41492 [ACK] Seq=1
Ack=5 Win=26880 Len=0 TSval=506027914 TSecr=721658601
  6   0.097055 172.31.15.199 -> 176.9.19.103 Socks 68 Version: 5 Connect to
server response
  7   0.193923 176.9.19.103 -> 172.31.15.199 TCP 66 41492→24042 [ACK] Seq=5
Ack=3 Win=29312 Len=0 TSval=721658625 TSecr=506027914
  8   0.193932 176.9.19.103 -> 172.31.15.199 Socks 98 Version: 5
  9   0.231965 172.31.15.199 -> 176.9.19.103 TCP 66 24042→41492 [ACK] Seq=3
Ack=37 Win=26880 Len=0 TSval=506027948 TSecr=721658625
 10   0.304031 172.31.15.199 -> 176.9.19.103 Socks 76 Version: 5 Command
Response - Unknown
 11   0.401323 176.9.19.103 -> 172.31.15.199 Socks 405 Version: 5
 12   0.401337 172.31.15.199 -> 176.9.19.103 TCP 66 24042→41492 [ACK] Seq=13
Ack=376 Win=28032 Len=0 TSval=506027990 TSecr=721658677
 13   0.496611 172.31.15.199 -> 176.9.19.103 Socks 158 Version: 5 Command
Response - Unknown
...

Let's try something different, putting the simple socks.port field (there is
only one connection here, and the port is 443, this value should only be in one
packet):
$ tshark -d tcp.port==24042,socks -r socks_example.pcap -T fields -e
frame.number -e socks.port
1    
2    
3    
4    
5    
6    
7    
8    
9    
10    0
11    
12    
13    20738
14    16384
15    
16    
17    
18    
19    
20    20684
...

You are receiving this mail because:
  • You are watching all bug changes.