>Synopsis: Possibly wrong information in tcpdump/print-domain.c
>Category: user
>Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
Architecture: OpenBSD.arm64
Machine : arm64
>Description:
print-domain.c in tcpdump has some bug. In fact it's not really sure
itself whether to print a label at 32 bytes or 63 bytes. Though according to
RFC 1034/1035 a label is maximally 63 bytes. There is some sort of EDNS0 mode
with bitmap lengths that I don't fully understand myself but it's there and
a crafted packet can give information that is possibly wrongly printed.
In print-domain.c there is function labellen() which maximally gives back a
labellen of 32 if it's one of these bitmap packets. In function
blabel_print() the variable lim is maximally 64 but the for loop will print
maximally 32 bytes in hex (so 64 characters). Let me show you some code:
109 slen = (bitlen + 3) / 4;
110 lim = cp + 1 + slen;
111
112 /* print the bit string as a hex string */
113 printf("\\[x");
114 for (bitp = cp + 1, b = bitlen; bitp < lim && b > 7; b -= 8, bit
p++) {
115 TCHECK(*bitp);
116 printf("%02x", *bitp);
117 }
Luckily this discrepancy can't be taken further and all it's doing is printing
possible misinformation in the tcpdump header, if (-X is not used you'll never
find out though what the true domain was I think).
>How-To-Repeat:
It looks like this in a specially crafted packet.
14:49:01.321764 192.168.177.13 > 255.255.255.255: gre [R] 0800 off 0x0
(rtaf=0x0) 192.168.177.13.59 > 255.255.255.255.53: [no udp cksum] 13352+ [1au]
A? \[x3132333435363738393031323334353637383930313233343536373839303132/256].(0)
(ttl 255, id 0, len 28) (ttl 255, id 0, len 20)
0000: 4500 0014 0000 0000 ff2f 4a05 c0a8 b10d E......../J.....
0010: ffff ffff 4000 0800 0000 0000 0000 00e8 ....@...........
0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0100: 0000 0000 0000 0000 0000 0000 4500 001c ............E...
0110: 0000 0000 ff11 4a1b c0a8 b10d ffff ffff ......J.........
0120: 003b 0035 0000 0000 3428 0100 0001 0000 .;.5....4(......
0130: 0000 0001 4100 3132 3334 3536 3738 3930 ....A.1234567890
0140: 3132 3334 3536 3738 3930 3132 3334 3536 1234567890123456
0150: 3738 3930 3132 0000 0100 0100 0100 0100 789012..........
0160: 2904 d000 0080 0000 00 )........
If you would like the file that generated this GRE packet with DNS information
in it, please mail me for it (I can only give it to @openbsd.org addresses).
>Fix:
I'm not going to fix this one, but I wanted to call out the bug!
dmesg:
See my other mails for this.
