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

Hi Colin,

Thanks — that matches how I understand the boundary as well. I'll treat it
as a robustness issue and prepare a minimal patch (drop the unnecessary
eval, quote the interface name).

Best regards, Nami Arjmandi

On Sun, Aug 9, 2026 at 5:20 PM Colin Percival <[email protected]> wrote:

> Hi Nami,
>
> I think DES's point is that if an unprivileged user can edit /etc/rc.conf,
> it's already game over since /etc/rc.conf is *code which is invoked as
> root*.
>
> I agree that avoiding eval and adding quoting could be useful for
> robustness
> reasons though.
>
> Colin Percival
>
> On 8/9/26 08:16, Nami Arjmandi wrote:
> > 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]
> > <mailto:[email protected]>> wrote:
> >
> >     Nami Arjmandi <[email protected] <mailto:[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]
> >
>
> --
> Colin Percival
> FreeBSD Release Engineering Lead & EC2 platform maintainer
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
>
>