Re: Command injection in /etc/rc.d/netif

Hi DES,

Thank you for your attention and for the question about the security
boundary.

*Reproductions (both run as root):*
*# Filename / glob*
touch '/tmp/;id;'
service netif start '/tmp/*'

*# rc.conf*
sysrc ifconfig_test=';id;'
service netif start test

In both cases `id` runs as root. An unprivileged user can plant the
filename (and, where permitted, influence config). They cannot invoke netif
by themselves on a stock system. The process that hits the eval is already
root.
So there is no classic unprivileged→root boundary crossing in base. I am
not claiming one.

*What happens*
The interface name (from the command line, including a glob-expanded
filename) and/or `ifconfig_*` values from rc.conf end up in constructs like:

eval ${IFCONFIG_CMD} $1 ${ifconfig_args}

Shell metacharacters are therefore executed with root privileges. Ordinary
word-splitting is enough for normal ifconfig arguments; this use of eval
does not appear necessary and is not the usual pattern in other rc services.

On real systems it is common to grant limited sudo/doas rights such as
passwordless `service netif *` (I have done this myself). Most people treat
that as “restart networking,” not “run arbitrary root commands via a
crafted filename or argument.” Because netif evals and expands those
values, that kind of rule is riskier than it looks. Users have no reason to
expect this from a standard rc script.
I understand if this is handled as a robustness fix rather than a security
advisory. I still believe the eval should go and the interface name should
be quoted. Happy to send a minimal patch through the normal path if that is
preferred.

Best regards,
Nami Arjmandi

On Sun, Aug 9, 2026 at 1:39 PM Dag-Erling Smørgrav <[email protected]> wrote:

> Nami Arjmandi <[email protected]> writes:
> > I have found netif script to be susceptible to command injection from
> > both command line and an arbitrary file name. It's probably happening
> > in /etc/network.subr but I have not yet been able to patch it.
>
> Can you explain exactly where a security boundary is being crossed?
>
> DES
> --
> Dag-Erling Smørgrav - [email protected]
>