From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14105 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Luke Shumaker Newsgroups: gmane.linux.lib.musl.general Subject: Malformed DNS requests for single-label hostnames with `search .` Date: Tue, 7 May 2019 12:29:43 -0400 Message-ID: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="263655"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14121-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 07 18:53:43 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hO3La-0016Us-Uq for gllmg-musl@m.gmane.org; Tue, 07 May 2019 18:53:43 +0200 Original-Received: (qmail 25966 invoked by uid 550); 7 May 2019 16:53:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9353 invoked from network); 7 May 2019 16:30:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datawire.io; s=google; h=mime-version:from:date:message-id:subject:to; bh=BKiN0I2gA9MK+zuPWsrtfpC3AFS/gd4KXbRNkCvxPj8=; b=I3DQEVoZWqRC8102n9Rkxo/YZaIU72n98d+l11jZszFd3BbKXdT5gdMyn0aDyaa0U3 5iC0Zd8TiBn6wPSb6IrnX1QyPRE1mSPx0d0tRuQOxfMXk1RSIM5nw6D1X4hdye8MQW2s VfycyG9en9ml7iFCTqxzVHiVvXCKJh5CZpl2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BKiN0I2gA9MK+zuPWsrtfpC3AFS/gd4KXbRNkCvxPj8=; b=KZhVIomOv+aqSFtXdJHJAcU61YQfBn20qwj/+cffUgo80szdj3vlYj37EYHkpV9E1Y bSEqUeLi80ZJB1znUEpWXyEaiLz/rdNQaT8dtHXaCb9wyDi7lpM6DZ9MZa3df7oZVGr/ apvhMP0oR6Wvd5Ke04pVztfm40KfpW2Y11mxb5Ao3Nk0yEwdYtGXxD9t5veH0LGiBwe7 JzdZvP44mTqcJ6JQFBgaPcWMKyjF8Uu5IfQj571eBNOIf6MSmUi6RFtvpKRiZtpqPxUh U/Ly3u7qP+CLseXPqPEY7gyzryd+NpZ4Y48+GW1ZS/SYlsywSyznubH8KhuVa82+OMsB DSNw== X-Gm-Message-State: APjAAAXwVSsvd8W1kmmwBHGAVNL8GChzuoD42dj+rKA3dh9iSMi15Jr7 hKtqYzc4FlfJcAZ3UTouhl1JewyOiNfC3iFjSRTzFiwMfIxENg== X-Google-Smtp-Source: APXvYqwC0BlMPsE0FX0K3/ovKajIKIYIVxUpGwi0WUkBEoYzrynYd3SfwtKIHWxY47+E3JrFpebtrelyDq0FhQMSn74= X-Received: by 2002:a24:29cd:: with SMTP id p196mr13043756itp.48.1557246594760; Tue, 07 May 2019 09:29:54 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:14105 Archived-At: 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