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

[gnats-admin%netbsd.org@localhost]

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

From: Henryk Paluch <hpaluch%seznam.cz@localhost>
To: gnats-bugs%netbsd.org@localhost, roy <roy%NetBSD.org@localhost>
Cc: 
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: Sat, 27 Dec 2025 16:57:33 +0100

 Anyway - original reported problem (resolvconf crashing on eval leaving 
 empty /etc/resolv.conf) seems to be fixed by Revision 1.13.2.2 for 
 netbsd-11 branch.
 
 Feel free to close this PR.
 
 
 On 12/25/25 16:35, Roy Marples via gnats wrote:
 ...
 >   
 >   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
 >