See below quoted text.
On Sun, Feb 26, 2023 at 03:08:42PM +0100, p...@delphinusdns.org wrote:
> >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.
Sundays is not my days or print-domain.c is too complex for me. I retract
this bug report. The only bug here is the variable lim in blabel_print().
I informed myself in the meanwhile on RFC 2673 which was deprecated by
RFC 6891. So this is a deprecated protocol (binary labels). I don't know
if it should linger around still in the code, that's up for you to decide.
Best Regards,
-peter
