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

["Henryk Paluch via gnats" <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
Cc: kre%munnari.OZ.AU@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: Tue, 16 Dec 2025 07:01:32 +0100

 Still, it is bad security practice to pass variable(s) in format string. 
 Any future change in variable processing may trigger unexpected change 
 in printf output behavior. Proper way would be something like:
 
 # TODO: properly quote $NAMESERVER content to avoid '"' escape in eval, 
 etc.:
 printf 'NAMESERVERS="%s" %s\n' "$(some_quote $NAMESERVERS)" "$(quote "$ns")"
 
 To be sure that printf format string is always valid and references 
 exactly 2 arguments no matter what content of arguments is.
 
 Or using echo which is immune to such things as long as start of 1st 
 argument does not contain '-'  which is no problem in our case where 
 string starts with literal.
 
 Additionally running whole output of make_vars using eval as root is 
 security nightmare on its own - because if any part of make_vars output 
 does not properly sanitize all content it may lead to root execution 
 exploit in future.
 
 Just this bug (not security one) demonstrated that eval problem pretty 
 well - when single quote in wrong place caused shell execution errors...
 
 
 However I'm not responsible for NetBSD security so I that's all I have 
 to say on this topic.
 
 On 12/15/25 21:50, Robert Elz via gnats wrote:
 > The following reply was made to PR bin/59836; it has been noted by GNATS.
 > 
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%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: Tue, 16 Dec 2025 03:48:16 +0700
 > 
 >       Date:        Mon, 15 Dec 2025 09:00:03 +0000 (UTC)
 >       From:        "Henryk Paluch via gnats" <gnats-admin%NetBSD.org@localhost>
 >       Message-ID:  <20251215090003.629BA1A923A%mollari.NetBSD.org@localhost>
 >   
 >     |  but it introduced new potential security bug, because it
 >     |  now passes untrusted user data ($NAMESERVERS) as format string to
 >     |  printf(1)
 >   
 >   No, it doesn't:
 >   
 >     |     printf 'NAMESERVERS="$NAMESERVERS "%s\n' "$(quote "$ns")"
 >   
 >   Look more carefully, it passes the characters:
 >   
 >   	NAMESERVERS=   (that part is obvious)
 >   	"
 >   	$
 >   	NAMESERVERS
 >   	space
 >   	"
 >   	%s
 >   	\n
 >   
 >   All enclosed in ' ' (no interpretation of what's in the string,
 >   other than what printf does - the %s gets the parameter's value,
 >   and the \n turns into a newline).
 >   
 >   The result should look something like (on stdout)
 >   
 >   	NAMESERVERS="$NAMESERVERS "'1.2.3.4'
 >   
 >   (and what is in $NAMESERVERS when the shell which processes that
 >   gets to see it will be all quoted strings, where the quotes will
 >   then be removed by doing an "eval").   The 1.2.3.4 is untrusted
 >   user data, but that's nicely hidden inside '' quotes.   It might not
 >   be useful as a nameserver, but it isn't going to do any harm.
 >   
 >   kre