| 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 |
[email protected]
|
| Reporter |
[email protected]
|
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 <[email protected]> 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.