Re: endless loop in tcpdump
On Mon, Oct 26 2020, "Peter J. Philipp" wrote: > On Sun, Oct 25, 2020 at 12:15:22AM +0200, Jeremie Courreges-Anglas wrote: >> >> dunno why the strange combination of To/Cc headers so I'll keep bugs@ in Cc: > > My answer is inline below: > >> On Sat, Oct 24 2020, p...@centroid.eu wrote: >> >>Synopsis: a specially crafted packet can set tcpdump into an endless loop >> >>Category: system >> >>Environment: >> >System : OpenBSD 6.8 >> >Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020 >> > >> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> > >> >Architecture: OpenBSD.amd64 >> >Machine : amd64 >> >>Description: >> >I was (un)fortunate enough to have this treat of a bug from a cracker >> > on the 'net. Thanks! They sent me an infinite loop in tcpdump. I bug >> > hunted >> > and shared my findings on the misc@ mailing list. I wasn't sure becuase >> > I'm >> > not the best code reader so I crafted a DOS to exploit this infinite loop. >> > I have mailed OpenBSD off-lists with this proof of concept code. >> >>How-To-Repeat: >> > before patch: >> > >> > tcpdump -v -n -i lo0 port >> > >> > 10:30:54.667969 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C >> > (teid 0, len 0) [MBMS Support] [MBMS Support] [MBMS Support] [MBMS >> > Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS >> > Support] [MBMS Support] [MBMS Support] [MBMS Support] ... >> > 2 packets received by filter >> > 0 packets dropped by kernel >> > >> > This was triggered with netcat: >> > >> > nc -up 2123 localhost < dos.packet >> > >> >>Fix: >> > after patch: >> > >> > tcpdump.p: listening on lo0, link-type LOOP >> > 10:43:41.005389 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C >> > (teid 0, len 0) [|GTPv1-C] (ttl 64, id 58060, len 41) >> > ^C >> > 2 packets received by filter >> > 0 packets dropped by kernel >> > spica# tcpdump.p -v -n -i lo0 -Xp-sp1500pport8 >> > tcpdump.p: listening on lo0, link-type LOOP >> > 10:44:11.956464 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C >> > (teid 0, len 0) [|GTPv1-C] (ttl 64, id 18693, len 41) >> > : 4500 0029 4905 4011 33bd 7f00 0001 E..)I...@.3. >> > 0010: 7f00 0001 084b 22b8 0015 a2bd 3400 .K".4... >> > 0020: 0001 00 . >> > >> > ^C >> > 2 packets received by filter >> > 0 packets dropped by kernel >> > >> > The patch looks like follows: >> > >> > Index: print-gtp.c >> > === >> > RCS file: /cvs/src/usr.sbin/tcpdump/print-gtp.c,v >> > retrieving revision 1.12 >> > diff -u -p -u -r1.12 print-gtp.c >> > --- print-gtp.c20 May 2020 01:20:37 - 1.12 >> > +++ print-gtp.c24 Oct 2020 08:56:00 - >> > @@ -927,6 +927,8 @@ gtp_v1_print(const u_char *cp, u_int len >> > >> >/* Header length is a 4 octet multiplier. */ >> >> I've never seen GTP in the wild but indeed a length of zero is invalid. >> In case it can help other reviewers: > > I was possibly not exploited as a natural DNS packet can trigger this. And > that's how I found this bug in the first place by tcpdumping DNS. Consider > this program to create the crafted packet: > > beta$ ./bad-packet > evil.2 > beta$ hexdump -C evil.2 > 34 00 00 00 00 01 00 00 00 00 00 02 00 00 00 00 |4...| > 0010 > beta$ vi bad-packet.c > beta$ cc -g -o bad-packet bad-packet.c > beta$ ./bad-packet > evil.2 > beta$ nc -up 2123 127.0.0.1 < evil.2 > > On the other screen then where I had a tcpdump on port (pretend it was > 53): > > rting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Info Change > Reporting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Info > Change Reporting] [MS Inf^C > 19 packets received by filter > > Same scenario only a bit different. The DNS packet then consists of: > > (from RFC 1035) > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | ID | > +
Re: endless loop in tcpdump
On Mon, Oct 26, 2020 at 08:23:15AM +0100, Peter J. Philipp wrote: > On the other screen then where I had a tcpdump on port (pretend it was > 53): ok sorry, that was a half-truth. I tried this out and it seems the DNS is printed over the 2123 port. However DNS on another port causes this for sure. Best Regards, -peter
Re: endless loop in tcpdump
On Sun, Oct 25, 2020 at 12:15:22AM +0200, Jeremie Courreges-Anglas wrote: > > dunno why the strange combination of To/Cc headers so I'll keep bugs@ in Cc: My answer is inline below: > On Sat, Oct 24 2020, p...@centroid.eu wrote: > >>Synopsis: a specially crafted packet can set tcpdump into an endless loop > >>Category: system > >>Environment: > > System : OpenBSD 6.8 > > Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > >>Description: > > I was (un)fortunate enough to have this treat of a bug from a cracker > > on the 'net. Thanks! They sent me an infinite loop in tcpdump. I bug > > hunted > > and shared my findings on the misc@ mailing list. I wasn't sure becuase I'm > > not the best code reader so I crafted a DOS to exploit this infinite loop. > > I have mailed OpenBSD off-lists with this proof of concept code. > >>How-To-Repeat: > > before patch: > > > > tcpdump -v -n -i lo0 port > > > > 10:30:54.667969 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C > > (teid 0, len 0) [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] > > [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] > > [MBMS Support] [MBMS Support] [MBMS Support] ... > > 2 packets received by filter > > 0 packets dropped by kernel > > > > This was triggered with netcat: > > > > nc -up 2123 localhost < dos.packet > > > >>Fix: > > after patch: > > > > tcpdump.p: listening on lo0, link-type LOOP > > 10:43:41.005389 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C > > (teid 0, len 0) [|GTPv1-C] (ttl 64, id 58060, len 41) > > ^C > > 2 packets received by filter > > 0 packets dropped by kernel > > spica# tcpdump.p -v -n -i lo0 -Xp-sp1500pport8 > > tcpdump.p: listening on lo0, link-type LOOP > > 10:44:11.956464 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C > > (teid 0, len 0) [|GTPv1-C] (ttl 64, id 18693, len 41) > > : 4500 0029 4905 4011 33bd 7f00 0001 E..)I...@.3. > > 0010: 7f00 0001 084b 22b8 0015 a2bd 3400 .K".4... > > 0020: 0001 00 . > > > > ^C > > 2 packets received by filter > > 0 packets dropped by kernel > > > > The patch looks like follows: > > > > Index: print-gtp.c > > === > > RCS file: /cvs/src/usr.sbin/tcpdump/print-gtp.c,v > > retrieving revision 1.12 > > diff -u -p -u -r1.12 print-gtp.c > > --- print-gtp.c 20 May 2020 01:20:37 - 1.12 > > +++ print-gtp.c 24 Oct 2020 08:56:00 - > > @@ -927,6 +927,8 @@ gtp_v1_print(const u_char *cp, u_int len > > > > /* Header length is a 4 octet multiplier. */ > > I've never seen GTP in the wild but indeed a length of zero is invalid. > In case it can help other reviewers: I was possibly not exploited as a natural DNS packet can trigger this. And that's how I found this bug in the first place by tcpdumping DNS. Consider this program to create the crafted packet: beta$ ./bad-packet > evil.2 beta$ hexdump -C evil.2 34 00 00 00 00 01 00 00 00 00 00 02 00 00 00 00 |4...| 0010 beta$ vi bad-packet.c beta$ cc -g -o bad-packet bad-packet.c beta$ ./bad-packet > evil.2 beta$ nc -up 2123 127.0.0.1 < evil.2 On the other screen then where I had a tcpdump on port (pretend it was 53): rting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Info Change Reporting] [MS Inf^C 19 packets received by filter Same scenario only a bit different. The DNS packet then consists of: (from RFC 1035) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QDCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |ANCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |NSCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
Re: endless loop in tcpdump
dunno why the strange combination of To/Cc headers so I'll keep bugs@ in Cc:
On Sat, Oct 24 2020, p...@centroid.eu wrote:
>>Synopsis: a specially crafted packet can set tcpdump into an endless loop
>>Category: system
>>Environment:
> System : OpenBSD 6.8
> Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
>>Description:
> I was (un)fortunate enough to have this treat of a bug from a cracker
> on the 'net. Thanks! They sent me an infinite loop in tcpdump. I bug hunted
> and shared my findings on the misc@ mailing list. I wasn't sure becuase I'm
> not the best code reader so I crafted a DOS to exploit this infinite loop.
> I have mailed OpenBSD off-lists with this proof of concept code.
>>How-To-Repeat:
> before patch:
>
> tcpdump -v -n -i lo0 port
>
> 10:30:54.667969 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C (teid
> 0, len 0) [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS
> Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS
> Support] [MBMS Support] [MBMS Support] ...
> 2 packets received by filter
> 0 packets dropped by kernel
>
> This was triggered with netcat:
>
> nc -up 2123 localhost < dos.packet
>
>>Fix:
> after patch:
>
> tcpdump.p: listening on lo0, link-type LOOP
> 10:43:41.005389 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C (teid
> 0, len 0) [|GTPv1-C] (ttl 64, id 58060, len 41)
> ^C
> 2 packets received by filter
> 0 packets dropped by kernel
> spica# tcpdump.p -v -n -i lo0 -Xp-sp1500pport8
> tcpdump.p: listening on lo0, link-type LOOP
> 10:44:11.956464 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C (teid
> 0, len 0) [|GTPv1-C] (ttl 64, id 18693, len 41)
> : 4500 0029 4905 4011 33bd 7f00 0001E..)I...@.3.
> 0010: 7f00 0001 084b 22b8 0015 a2bd 3400 .K".4...
> 0020: 0001 00 .
>
> ^C
> 2 packets received by filter
> 0 packets dropped by kernel
>
> The patch looks like follows:
>
> Index: print-gtp.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/print-gtp.c,v
> retrieving revision 1.12
> diff -u -p -u -r1.12 print-gtp.c
> --- print-gtp.c 20 May 2020 01:20:37 - 1.12
> +++ print-gtp.c 24 Oct 2020 08:56:00 -
> @@ -927,6 +927,8 @@ gtp_v1_print(const u_char *cp, u_int len
>
> /* Header length is a 4 octet multiplier. */
I've never seen GTP in the wild but indeed a length of zero is invalid.
In case it can help other reviewers:
https://www.etsi.org/deliver/etsi_ts/129000_129099/129060/15.05.00_60/ts_129060v150500p.pdf
> hlen = (int)p[0] * 4;
> + if (hlen == 0)
> + goto trunc;
LGTM, though I'd suggest printing why we're bailing out.
Index: print-gtp.c
===
RCS file: /d/cvs/src/usr.sbin/tcpdump/print-gtp.c,v
retrieving revision 1.12
diff -u -p -p -u -r1.12 print-gtp.c
--- print-gtp.c 20 May 2020 01:20:37 - 1.12
+++ print-gtp.c 24 Oct 2020 22:02:47 -
@@ -927,6 +927,11 @@ gtp_v1_print(const u_char *cp, u_int len
/* Header length is a 4 octet multiplier. */
hlen = (int)p[0] * 4;
+ if (hlen == 0) {
+ printf(" [Invalid zero-length header %u]",
+ nexthdr);
+ goto trunc;
+ }
TCHECK2(p[0], hlen);
switch (nexthdr) {
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
endless loop in tcpdump
>Synopsis: a specially crafted packet can set tcpdump into an endless loop
>Category: system
>Environment:
System : OpenBSD 6.8
Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I was (un)fortunate enough to have this treat of a bug from a cracker
on the 'net. Thanks! They sent me an infinite loop in tcpdump. I bug hunted
and shared my findings on the misc@ mailing list. I wasn't sure becuase I'm
not the best code reader so I crafted a DOS to exploit this infinite loop.
I have mailed OpenBSD off-lists with this proof of concept code.
>How-To-Repeat:
before patch:
tcpdump -v -n -i lo0 port
10:30:54.667969 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C (teid 0,
len 0) [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS
Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS Support] [MBMS
Support] [MBMS Support] [MBMS Support] ...
2 packets received by filter
0 packets dropped by kernel
This was triggered with netcat:
nc -up 2123 localhost < dos.packet
>Fix:
after patch:
tcpdump.p: listening on lo0, link-type LOOP
10:43:41.005389 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C (teid 0,
len 0) [|GTPv1-C] (ttl 64, id 58060, len 41)
^C
2 packets received by filter
0 packets dropped by kernel
spica# tcpdump.p -v -n -i lo0 -Xp-sp1500pport8
tcpdump.p: listening on lo0, link-type LOOP
10:44:11.956464 127.0.0.1.2123 > 127.0.0.1.: [udp sum ok] GTPv1-C (teid 0,
len 0) [|GTPv1-C] (ttl 64, id 18693, len 41)
: 4500 0029 4905 4011 33bd 7f00 0001 E..)I...@.3.
0010: 7f00 0001 084b 22b8 0015 a2bd 3400 .K".4...
0020: 0001 00 .
^C
2 packets received by filter
0 packets dropped by kernel
The patch looks like follows:
Index: print-gtp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-gtp.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 print-gtp.c
--- print-gtp.c 20 May 2020 01:20:37 - 1.12
+++ print-gtp.c 24 Oct 2020 08:56:00 -
@@ -927,6 +927,8 @@ gtp_v1_print(const u_char *cp, u_int len
/* Header length is a 4 octet multiplier. */
hlen = (int)p[0] * 4;
+ if (hlen == 0)
+ goto trunc;
TCHECK2(p[0], hlen);
switch (nexthdr) {
dmesg:
OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct 4 18:13:26 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17059287040 (16269MB)
avail mem = 16527237120 (15761MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afac000 (32 entries)
bios0: vendor Apple Inc. version "186.0.0.0.0" date 06/14/2019
bios0: Apple Inc. MacBookPro12,1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT DMAR MCFG
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4)
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.35 MHz, 06-3d-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2800.01 MHz, 06-3d-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way
