[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
