fix-host_txt_rdata.patch

[nomas2000]

The TXT RR RDATA returned by DNS servers is rfc1035 <character-string>s
<character-string> is a single length octet followed by that number of characters. 
... notice how the first RDATA byte is usually 1-less than the RDLENGTH?

If max allowed TXT record length is 255 chars + we assume only one char string,
then we can just verify and discard the first byte of TXT RDATA. If first byte
doesn't match (1 shorter than RDLENGTH) then don't discard it.
... throw an error instead? ... ignore the response as invalid?


--- toybox-0.8.6/toys/pending/host.c_ORIG	2022-07-25 17:30:48.958174663 +0000
+++ toybox-0.8.6/toys/pending/host.c	2022-07-25 17:32:40.178209094 +0000
@@ -170,6 +170,10 @@
         dn_expand(abuf, abuf+alen, p, plname, sizeof(plname));
         break;
       case PL_TEXT:
+        if ((pllen > 1) && (pllen <= 256) && (pllen-1 == p[0])) {
+          pllen--;
+          p++;
+        }
         snprintf(plname, sizeof(plname), "\"%.*s\"", pllen, p);
         break;
       case PL_SOA:

[landley]

If you do these as pull requests instead of issues I can easily apply them with your supplied metadata. (I.E. proper attribution.) FYI.

[enh-google]

almost two whole years ... probably time to just do it without attribution?

[landley]

On 11/2/22 12:42, nomas2000 wrote: ``` The TXT RR RDATA returned by DNS servers is rfc1035 <character-string>s <character-string> is a single length octet followed by that number of characters. ... notice how the first RDATA byte is usually 1-less than the RDLENGTH? If max allowed TXT record length is 255 chars + we assume only one char string, then we can just verify and discard the first byte of TXT RDATA. If first byte doesn't match (1 shorter than RDLENGTH) then don't discard it. ... throw an error instead? ... ignore the response as invalid?

Sorry for sitting on this so long, the problem is I can't find a test site that actually returns a non-truncated packet for any -t txt search. What server did you test this with? For example the return from google.com has "docusign=" and "verification" strings for apple and facebook and cisco. It seems that most DNS servers only want to return UDP packets of 512 bytes maximum, and set the "truncated" flag with no payload on anything larger. According to strace -f, Debian's "host" command will fall back to TCP for a UDP return packet with the truncated bit set, even when given the -U flag. I can apply your patch, but does it fix the issue? (Is there a fix other than implementing TCP/IP mode?)

[nomas2000]

?? Just stop including (outputting) the leading LENGTH byte in the result !!

4.34636: [udp sum ok] 38096*- q: TXT? facebook.com. 5/0/0 facebook.com. [2h] TXT "google-site-verification=A2WZWCNQHrGV_TWwKh6KHY90tY0SHZo_RnyMJoDaG0s", facebook.com. [2h] TXT "google-site-verification=sK6uY9x7eaMoEMfn3OILqwTFYgaNp4llmguKI-C3_iA", facebook.com. [2h] TXT "google-site-verification=wdH5DTJTc9AYNwVunSVFeK0hYDGUIEOGb-RReU6pJlY", facebook.com. [1h] TXT "zoom-domain-verification=4b2ef4e1-6dee-4483-9869-9bef353fd147", facebook.com. [1d] TXT "v=spf1 redirect=_spf.facebook.com" (393)
        0x0000:  0000 0001 0006 0008 7c27 7800 0000 0800  ........|'x.....
        0x0010:  4500 01a5 68d5 4000 4d11 0fbe 8186 1e0c  [email protected].......
        0x0020:  ac1e 6804 0035 874c 0191 272c 94d0 8500  ..h..5.L..',....
        0x0030:  0001 0005 0000 0000 0866 6163 6562 6f6f  .........faceboo
        0x0040:  6b03 636f 6d00 0010 0001 c00c 0010 0001  k.com...........
        0x0050:  0000 1c20 0045 4467 6f6f 676c 652d 7369  .....EDgoogle-si
        0x0060:  7465 2d76 6572 6966 6963 6174 696f 6e3d  te-verification=
        0x0070:  4132 575a 5743 4e51 4872 4756 5f54 5777  A2WZWCNQHrGV_TWw
        0x0080:  4b68 364b 4859 3930 7459 3053 485a 6f5f  Kh6KHY90tY0SHZo_
        0x0090:  526e 794d 4a6f 4461 4730 73c0 0c00 1000  RnyMJoDaG0s.....
        0x00a0:  0100 001c 2000 4544 676f 6f67 6c65 2d73  ......EDgoogle-s
        0x00b0:  6974 652d 7665 7269 6669 6361 7469 6f6e  ite-verification
        0x00c0:  3d73 4b36 7559 3978 3765 614d 6f45 4d66  =sK6uY9x7eaMoEMf
        0x00d0:  6e33 4f49 4c71 7754 4659 6761 4e70 346c  n3OILqwTFYgaNp4l
        0x00e0:  6c6d 6775 4b49 2d43 335f 6941 c00c 0010  lmguKI-C3_iA....
        0x00f0:  0001 0000 1c20 0045 4467 6f6f 676c 652d  .......EDgoogle-
        0x0100:  7369 7465 2d76 6572 6966 6963 6174 696f  site-verificatio
        0x0110:  6e3d 7764 4835 4454 4a54 6339 4159 4e77  n=wdH5DTJTc9AYNw
        0x0120:  5675 6e53 5646 654b 3068 5944 4755 4945  VunSVFeK0hYDGUIE
        0x0130:  4f47 622d 5252 6555 3670 4a6c 59c0 0c00  OGb-RReU6pJlY...
        0x0140:  1000 0100 000e 1000 3e3d 7a6f 6f6d 2d64  ........>=zoom-d
        0x0150:  6f6d 6169 6e2d 7665 7269 6669 6361 7469  omain-verificati
        0x0160:  6f6e 3d34 6232 6566 3465 312d 3664 6565  on=4b2ef4e1-6dee
        0x0170:  2d34 3438 332d 3938 3639 2d39 6265 6633  -4483-9869-9bef3
        0x0180:  3533 6664 3134 37c0 0c00 1000 0100 0151  53fd147........Q
        0x0190:  8000 2221 763d 7370 6631 2072 6564 6972  .."!v=spf1.redir
        0x01a0:  6563 743d 5f73 7066 2e66 6163 6562 6f6f  ect=_spf.faceboo
        0x01b0:  6b2e 636f 6d     

Address:        129.134.30.12#53
facebook.com    text = "google-site-verification=A2WZWCNQHrGV_TWwKh6KHY90tY0SHZo_RnyMJoDaG0s"
facebook.com    text = "google-site-verification=sK6uY9x7eaMoEMfn3OILqwTFYgaNp4llmguKI-C3_iA"
facebook.com    text = "google-site-verification=wdH5DTJTc9AYNwVunSVFeK0hYDGUIEOGb-RReU6pJlY"
facebook.com    text = "zoom-domain-verification=4b2ef4e1-6dee-4483-9869-9bef353fd147"
facebook.com    text = "v=spf1 redirect=_spf.facebook.com"

        0x0140:  1000 0100 000e 1000 3e3d 7a6f 6f6d 2d64  ........>=zoom-d
        0x0150:  6f6d 6169 6e2d 7665 7269 6669 6361 7469  omain-verificati
        0x0160:  6f6e 3d34 6232 6566 3465 312d 3664 6565  on=4b2ef4e1-6dee
        0x0170:  2d34 3438 332d 3938 3639 2d39 6265 6633  -4483-9869-9bef3
        0x0180:  3533 6664 3134 37c0 0c00 1000 0100 0151  53fd147........Q

3d + 7a6f 6f6d 2d64  ........>=zoom-d
0x3d is 61
zoom-domain-verification=4b2ef4e1-6dee-4483-9869-9bef353fd147
1234567890123456789012345678901234567890123456789012345678901
... which actually seems wrong?
(maybe leading '=' is "ignored" b/c 0x3e is 62, which makes sense)
(would need to decode the whole packet to know which byte is the len)

        0x0190:  8000 2221 763d 7370 6631 2072 6564 6972  .."!v=spf1.redir
        0x01a0:  6563 743d 5f73 7066 2e66 6163 6562 6f6f  ect=_spf.faceboo
        0x01b0:  6b2e 636f 6d     
that " is really LENGTH 0x22 or 34
v=spf1 redirect=_spf.facebook.com
1234567890123456789012345678901234

[landley]

"You can currently test against facebook.com." Thanks, that's what I needed. Commit 4b238cf