|
Message-ID: <CABuoFAF8p7UoTsEcmVwvt3FijVqxZrJ8F4i8VVAb8Tanz_v8wg@mail.gmail.com> Date: Tue, 7 May 2019 12:29:43 -0400 From: Luke Shumaker <lukeshu@...awire.io> To: musl@...ts.openwall.com Subject: Malformed DNS requests for single-label hostnames with `search .` In some scenarios, musl libc generates invalid DNS queries that are discarded by the DNS server. Particularly when `resolv.conf` says `search .` and we attempt to resolv a single-label hostname. / # cat /etc/resolv.conf search . nameserver 1.1.1.1 For context of "what it should do", if I have a trailing `.` to tell it to ignore the `search`-path, it makes the request correctly: / # time strace -f -e trace=sendto,sendmsg,sendmmsg getent hosts label. sendto(3, "\214\302\1\0\0\1\0\0\0\0\0\0\5label\0\0\34\0\1", 23, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 23 sendto(3, "\355b\1\0\0\1\0\0\0\0\0\0\5label\0\0\1\0\1", 23, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 23 +++ exited with 2 +++ Command exited with non-zero status 2 real 0m 0.03s user 0m 0.00s sys 0m 0.00s But if I allow it to use the `search`-path, the query is invalid: / # time strace -f -e trace=sendto,sendmsg,sendmmsg getent hosts label sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 24 sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 24 sendto(3, "\363\365\1\0\0\1\0\0\0\0\0\0\5label.\0\1\0\1\0", 24, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 24 sendto(3, "\363\365\1\0\0\1\0\0\0\0\0\0\5label.\0\1\0\1\0", 24, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 24 +++ exited with 2 +++ Command exited with non-zero status 2 real 0m 10.01s user 0m 0.00s sys 0m 0.00s We see it take 10s to time-out waiting for a reply from the DNS server that will never come (because the server ignored the query as malformed). To annotate the queries a bit: Good request: sendto(3, "\214\302\1\0\0\1\0\0\0\0\0\0\5label\0\0\34\0\1", 23, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 23 [ header-section [question-section] [-----][][---][--] ^ ^ ^ ^ QNAME[0] = octet[5]{"label"} --' | | | QNAME[1] = end -----------------------' | | QTYPE = AAAA ------------------------' | QCLASS = IN -------------------------------' Bad request (as seen by a parser) sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 24 [ header-section [question-section ] [-----][----------- - - - ^ ^ QNAME[0] = octet[5]{"label"} -----' | QNAME[1] = octet[46]{"\0\34\0\1\0"...} --' QNAME[n] = end --------------------------------------- - - - QTYPE = ??? --------------------------------------- - - - QCLASS = ??? --------------------------------------- - - - Bad request (as seen by a human): sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.1.1.1")}, 16) = 24 [ header-section [question-section ] [-----]|[---][--][] ^ ^^ ^ ^ QNAME[0] = octet[5]{"label"} -----' || | | QNAME[1] = should-be-end -----------------' | | | QTYPE = AAAA --------------------------' | | QCLASS = IN ---------------------------------' | garbage = garbage --------------------------------' So there are 2 pieces of corruption going on here: 1. Instead of getting the \0 terminator indicating that there are no more lables in the QNAME, it gets an ASCII '.', indicating another label of length 46. 2. An extra byte is allocated, which appears at the end of the message. I have verified that the error happens with: - Alpine 3.9's musl 1.1.20-r3 on x86_64 - Alpine 3.9's musl 1.1.20-r4 on x86_64 - Alpine edge's musl 1.1.21-r2 on x86_64 - Alpine edge's musl 1.1.22-r0 on x86_64 -- Happy hacking, ~ Luke Shumaker
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.