[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 Peter Wu changed: What|Removed |Added Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #12 from Peter Wu --- Fixed in v2.5.2rc0-60-gaf8ac43a1f and v2.4.6rc0-54-g2d4695de14. Could not reproduce the crash in master-2.2 though. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 --- Comment #11 from Gerrit Code Review --- Change 26586 merged by Peter Wu: tcp: preserve data source if a PDU uses it https://code.wireshark.org/review/26586 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 --- Comment #10 from Gerrit Code Review --- Change 26586 had a related patch set uploaded by Peter Wu: tcp: preserve data source if a PDU uses it https://code.wireshark.org/review/26586 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 --- Comment #9 from Gerrit Code Review --- Change 26397 merged by Peter Wu: tcp: preserve data source if a PDU uses it https://code.wireshark.org/review/26397 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 --- Comment #8 from Peter Wu --- In fact, two packets are sufficient to trigger the issue: IP()/TCP(sport=8080, dport=2575, flags="A", seq=1)/data1, IP()/TCP(sport=8080, dport=2575, flags="SA", seq=1+len(data1))/data2, The first packet is decoded as hl7 (because port 2575 (hl7) < 8080 (http)), the second packet is decoded as http (because SYN/ACK selects port 8080). -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472
--- Comment #7 from Peter Wu ---
Created attachment 16210
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16210&action=edit
Crafted crash reproducer
The previously proposed patch is insufficient, if the first TCP segment
contains the full HTTP message (+ a bit more), then the same crash would occur.
See attached pcap, crafted with the following script:
from scapy.all import *
data1 = b"HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nTest\n"
data2 = b"HTTP/1.1 400 Bad Request\r\n" # note: missing \r\n
data1, data2 = data1 + data2[:1], data2[1:]
p = [
IP()/TCP(sport=8080, dport=2575, flags="A", seq=1)/data1,
IP()/TCP(sport=8080, dport=2575, flags="SA", seq=1),
IP()/TCP(sport=8080, dport=2575, flags="A", seq=1+len(data1))/data2,]
wrpcap("bug14472-badhttp.pcap", p)
Note that both the original and this capture requires the default configuration
(TCP and possibly HTTP headers reassembly must be enabled)
--
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 --- Comment #6 from Gerrit Code Review --- Change 26397 had a related patch set uploaded by Peter Wu: tcp: preserve data source if a PDU uses it https://code.wireshark.org/review/26397 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472
Peter Wu changed:
What|Removed |Added
Status|CONFIRMED |IN_PROGRESS
--- Comment #5 from Peter Wu ---
More details:
remove_last_data_source was added in v1.11.3-rc1-1525-g21e0a63b29 to resolve
bug 9169.
If you disable TCP reassembly for subdissectors, you'll actually find a full
HTTP response in packet 1. In packet 3, there is no Content-Length header, so
the HTTP dissector tries reassembly via
desegment_len=DESEGMENT_ONE_MORE_SEGMENT and
desegment_offset=1206 (the length of TCP segment in frame 1?!)
Also confirmed that none of trigger the crash:
- The order is important, packets 2-1-3 do not trigger the problem.
- Changing seqno of packet 2 (to match packet 1).
- Removal of packet 1 or 2, each packet seems significant.
- Removing SYN from packet 2 (and on top of that, changing seqno to match
packet 1).
Further investigation showed the following that explains why packet 1 does not
have a HTTP message:
In frame 1, dissect_hl7 is called because port 2575 (hl7) < 8080 (http), that
dissector sets desegment_len=DESEGMENT_ONE_MORE_SEGMENT. TCP starts reassembly.
In frame 2, dissect_tcp (packet-tcp.c:6122) sees SYN+ACK and assume that this
source port (8080) is actually the server port.
In frame 3, the dissector for port 8080 (http) takes precedence and finds two
HTTP messages in the reassembled TCP data.
And finally it becomes clear why TCP branches into this:
/* call subdissector */
process_tcp_payload(...);
// ...
old_len = (int)(tvb_reported_length(next_tvb) - last_fragment_len);
if (pinfo->desegment_len &&
pinfo->desegment_offset<=old_len) {
// ...
remove_last_data_source(pinfo);
last_fragment_len (i.e. the length of the first TCP segment from packet 1) is
1206. That contained exactly one HTTP message. The last segment however does
not have a Content-Length header and thus HTTP requests one more segment,
starting right after desegment_offset=1206. And thus, the condition passes:
if (DESEGMENT_ONE_MORE_SEGMENT &&
1206 <= 1206) {
However, what TCP did not know is that HTTP actually added fields based on the
first 1206 bytes of the "reassembled" TCP data. I think that if
desegment_offset == old_len, then it means that the last segment in fact
contained a full PDU and thus the data source must not be removed.
--
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472
Peter Wu changed:
What|Removed |Added
CC||pe...@lekensteyn.nl
--- Comment #4 from Peter Wu ---
Reproduced with v2.5.1rc0-544-g1ac90d5254 using Clang 5.0.1 and:
tshark -r 565c34461815a4dc3ec8d603ad273bb5.pcap -V
Possible relevant information about the capture:
Frame 1 has seqno 1, len = 1206, nextseq=1207
Frame 2 has seqno 4261299399 (0xfdfe44c7), len=0 (marked as out-of-order)
Frame 3 has seqno 1207 (len=1204)
For some weird reason, "src_list" contains only one data source (Frame) while
"fi->ds_tvb" was allocated via desegmented TCP data:
(gdb) down
#4 0x7fffecc3a4eb in get_field_data (src_list=0x60200044b1f0 = {...},
fi=0x6083bc20) at epan/print.c:1758
1758g_assert_not_reached();
(gdb) p fi->ds_tvb
$5 = (tvbuff_t *) 0x607d3980
(gdb) p (void)__asan_describe_address (0x607d3980)
0x607d3980 is located 0 bytes inside of 72-byte region
[0x607d3980,0x607d39c8)
allocated by thread T0 here:
#0 0x556ef771 in malloc (run/tshark+0x19b771)
#1 0x7fffdebf35a9 in g_malloc /build/src/glib/glib/gmem.c:94
#2 0x7fffece37e73 in tvb_new_with_subset epan/tvbuff_subset.c:101:18
#3 0x7fffece3948c in tvb_new_proxy epan/tvbuff_subset.c:214:9
#4 0x7fffece188c5 in tvb_new_chain epan/tvbuff.c:131:18
#5 0x7fffeb242306 in desegment_tcp epan/dissectors/packet-tcp.c:3183:24
#6 0x7fffeb23ef8b in dissect_tcp_payload
epan/dissectors/packet-tcp.c:5684:9
#7 0x7fffeb2610fa in dissect_tcp epan/dissectors/packet-tcp.c:6522:13
...
(gdb) p src_list
$10 = 0x60200044b1f0 = {0x60200044b1b0}
(gdb) p *(struct data_source*)src_list[0]->data
$14 = {tvb = 0x608383a0, name = 0x60200044b1d0 "Frame"}
(gdb) p (void) __asan_describe_address (0x608383a0)
0x608383a0 is located 0 bytes inside of 88-byte region
[0x608383a0,0x608383f8)
allocated by thread T0 here:
#0 0x556ef771 in malloc (run/tshark+0x19b771)
#1 0x7fffdebf35a9 in g_malloc /build/src/glib/glib/gmem.c:94
#2 0x55802b02 in frame_tvbuff_new frame_tvbuff.c:169:8
#3 0x5575789d in process_packet_single_pass tshark.c:3523:32
#4 0x55750bd7 in process_cap_file tshark.c:3348:11
#5 0x55748586 in main tshark.c:2029:17
Since the TCP tvb is not added as data source, I would have expected it to use
the frame tvb instead but clearly that is not happening. The data source was
not visible because "remove_last_data_source" actually removed it.
Initial guess: to fix this issue, we must ensure that the tvb that was removed
by remove_last_data_source is not used anywhere.
--
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 Pascal Quantin changed: What|Removed |Added Status|INCOMPLETE |CONFIRMED --- Comment #3 from Pascal Quantin --- Using clang (instead of gcc) with the options provided allows to reproduce the issue. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 --- Comment #2 from otto.air...@gmail.com --- I pulled latest changes: commit dd21b8130c6470d2d5076fcc46d5e9c3866f4609 Compiled: export CC=clang export CXX=clang++ export CFLAGS="-g -O2 -fsanitize=address -fsanitize-coverage=edge -fno-omit-frame-pointer" export CXXFLAGS="-g -O2 -fsanitize=address -fsanitize-coverage=edge -fno-omit-frame-pointer" export CPPFLAGS="-g -O2 -fsanitize=address -fsanitize-coverage=edge -fno-omit-frame-pointer" export LDFLAGS="-g -fsanitize=address -fsanitize-coverage=edge" ./autogen.sh ./configure --enable-static=no --enable-shared=yes --enable-wireshark=no --enable-editcap=no --enable-capinfos=no --enable-mergecap=no --enable-reordercap=no --enable-text2pcap=no --enable-dftest=no --enable-randpkt=no --enable-dumpcap=yes --enable-rawshark=no make Executed command: tshark -2 -V -r 565c34461815a4dc3ec8d603ad273bb5.pcap Sorry, original post was missing tshark command. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 14472] Crafted HTTP traffic causes tshark to abort
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14472 Pascal Quantin changed: What|Removed |Added CC||pascal.quan...@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |INCOMPLETE --- Comment #1 from Pascal Quantin --- I cannot reproduce it with v2.5.1rc0-451-gb99b9b81. Could you please verify if you can reproduce it with current top of tree, and if yes could you share your Wireshark user profile? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
