Re: bin/59836: 11.0_BETA: resolvconf fails with 'eval: make_vars: IP_OF_2ND_DNS: not found' for more than 1 dns server

["Roy Marples via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59836; it has been noted by GNATS.

From: Roy Marples <roy%marples.name@localhost>
To: "Henryk Paluch" <hpaluch%seznam.cz@localhost>
Cc: "gnats-bugs" <gnats-bugs%netbsd.org@localhost>, "roy" <roy%NetBSD.org@localhost>
Subject: Re: bin/59836: 11.0_BETA: resolvconf fails with 'eval: make_vars:
 IP_OF_2ND_DNS: not found' for more than 1 dns server
Date: Thu, 25 Dec 2025 15:34:00 +0000

  ---- On Thu, 18 Dec 2025 13:26:13 +0100  Henryk Paluch <hpaluch%seznam.cz@localhost> wrote --- 
 >  And here it comes...
 >
 > ===
 >  https://www.freebsd.org/security/advisories/FreeBSD-SA-25:12.rtsold.asc
 >
 > resolvconf(8) is a shell script which does not validate its input.  A 
 > lack of
 > quoting meant that shell commands pass as input to resolvconf(8) may be
 > executed.
 > ===
 
 > So my complains on resolvconf(8) security are not as baseless as many 
 > people wish...
 
 I don't think anyone said they were baseless. And the FreeBSD sec team notified me of this issue some time ago, hence this new release to solve the problem.
 The root cause is in FreeBSD rtsold as it's not validating it's input.
 
 resolvconf works by parsing a resolv.conf(5) file fed in per key and we make no claims as to what constitutes a valid entry because every libc resolver is different and supports different options.
 nameserver should be a valid IPv4 or IPv6 address.
 The domain or search entries *should* contain alphanumberics only as per RFC1053 (allowing for - in the middle) and each label *should* be at most 63 characters, you get the idea.
 
 IPv8 might come along and use the $ or ` symbol in the address makeup for example - resolvconf should still work.
 The local libc might work with punycode natively allowing non alphanumerics in the search, which again would break resolvconf validation.
 resolvconf doest not know this and shouldn't have to know this - it just edits /etc/resolv.conf and configures nameservers from it's input which should already be sanitized by the higher level protocols which know how their
 protocol demands it's delivered.
 
 No, this is purely a quoting issue for resolvconf. The design is basically process each resolv.conf file in order and extract key/values from it, process and output the final variables.
 Because the input is fed in via a pipe into a while .. read ... done loop we have to eval the variables back in as a pipe cannot changes variables in the main process.
 
 For NetBSD at least this is a none issue as dhcpcd ensures that this attack cannot happen because the DHCP/DHCPv6/RA RFC's mandate DNS restrictions so that these special shell escape characters don't even hit resolvconf.
 Something that should be fixed? Sure.
 Remote exploit? Not for NetBSD.
 
 Roy