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: 
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, 18 Dec 2025 13:26:13 +0100

 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...
 
 
 On 12/17/25 01:32, Robert Elz wrote:
 >      Date:        Tue, 16 Dec 2025 07:01:32 +0100
 >      From:        Henryk Paluch <hpaluch%seznam.cz@localhost>
 >      Message-ID:  <37b539e1-f624-4b10-9a90-c55181758b3f%seznam.cz@localhost>
 > 
 >    | Still, it is bad security practice to pass variable(s) in format string.
 > 
 > Variables that contain unknown data, yes, it is.
 > 
 > But you still seem to be missing the point.  That is not what was
 > happening here, the format string contained (contains) no variables
 > at all.
 > 
 > Consider this example
 > 
 > 	printf '$(cat /dev/tty)\n'
 > 
 > What that writes out is (literally)
 > 
 > 	$(cat /dev/tty)
 > 
 > (including a newline of course).   There is no command substitution, no
 > commands run, no reference to any device, just a string of characters
 > written to standard output.
 > 
 > That the string happens to look like a command substitution (in this
 > case) or a variable reference (in the resolvconf case) makes no
 > difference to anything, it is just a string of characters.
 > 
 > Once again, in sh, NOTHING inside a single quoted string is interpreted
 > by the shell in any way at all.   That includes dollar signs, double quotes,
 > backslashes, grave accents (backticks), braces, ... the only character the
 > shell looks for in a single quoted string is the next single quote, which
 > ends the thing.   And that is what the format string given used, just like
 > the example above.
 > 
 > The format string for printf should usually (when it needs any quoting)
 > be quoted using single quotes -- except in the very rare case when var
 > references ae actually needed there - which, if you want to be portable,
 > can be needed if, for example, the script wants to calculate field
 > widths, you might have a loop calculating the width needed something
 > like:
 > 
 > 	W=0
 > 	for X
 > 	do
 > 		if [ "${#X}" -gt "$W" ]
 > 		then
 > 			W=${#X}
 > 		fi
 > 	done
 > 	W=$(( W + 1 ))		# One more than the longest
 > 
 > 	for X
 > 	do
 > 		printf "%-${W}s [other stuff]\n" "$X"  [other args]
 > 	done
 > 
 > In our printf (and many others) you might instead do
 > 
 > 		printf '%-*s [other stuff]\n' "$W" "$X" [other args]
 > 
 > but support for '*' as the field width (or precision), isn't required
 > by POSIX, precisely because the version with the embedded $W reference
 > is possible (and perfectly safe - we know what kind of data must be in $W,
 > it has to be a number, and nothing else.)
 > 
 > 
 > 
 >    | # TODO: properly quote $NAMESERVER content to avoid '"' escape in eval,
 >    | etc.:
 >    | printf 'NAMESERVERS="%s" %s\n' "$(some_quote $NAMESERVERS)" "$(quote "$ns")"
 > 
 > No it wouldn't, that's using the value of $NAMESERVERS (and quoting it
 > however the fictional some_quote function does it, which is irrelevant
 > here) which the original does not do.  It didn't, even in its earlier
 > incarnations.   The *only* variable expansion is of $ns.  The one in
 > resolvconf writes the characters dollar, N, A, M, E, S, E, ... where
 > you think it is writing the value of a variable.   I thought that was
 > clear from my previous reply.
 > 
 >    | Or using echo which is immune to such things
 > 
 > echo is close to useless in portable programs.  There are versions
 > of it which treat \ in the string (anywhere, the only way to prevent it
 > is to use \\, and if we're assuming user data, we cannot assume that)
 > to cause strange variations, and since this output is to be interpreted
 > by a shell later, as commands (I presume), allowing a \n to get in there
 > possibly followed by "rm -fr / &" and another newline after that, would
 > be nasty indeed.   echo is never better than printf (just sometimes it
 > is quicker to type,  echo is a shorter word than printf, and doesn't need
 > a format string arg, so lazy script writers tend to use it (and of
 > course it was around for many years before printf was, but by comparison
 > with how long printf has been available now, that's almost irrelevant.)
 > 
 > Original Bell labs echo doesn't do that, and BSD echo doesn't do that,
 > but Sys V (and POSIX) versions of echo do - even though these days POSIX
 > says that if the string starts with a '-' or contains a \ then the
 > results are unspecified (which is no help to us, or anyone, at all.)
 > 
 >    | 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.
 > 
 > This one I can't comment on, as I have no idea what the relevance is
 > to the issue, nor what might be doing something like that, nor why.
 > 
 > kre
 >