HN Reader

> 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.

The fix consists of implementing an XXX present since the code was added:

    /*
     * XXX validate that domain name only contains valid characters
     * for two reasons: 1) correctness, 2) we do not want to pass
     * possible malicious, unescaped characters like `` to a script
     * or program that could be exploited that way.
     */

https://www.freebsd.org/security/patches/SA-25:12/rtsold.pat...

This actually makes me happy! I must be getting old!

It truly is a bad one but I really appreciate Kevin Day for finding/reporting this and for all the volunteer work fixing this.

All I had to do was "freebsd-update fetch install && reboot" on my systems and I could continue my day. Fleet management can be that easy for both pets and cattle. I do however feel for those who have deployed embedded systems. We can only hope the firmware vendors are on top of their game.

My HN addiction is now vindicated as I would probably not have noticed this RCE until after christmas.

This makes me very grateful and gives me a warm fuzzy feeling inside!

Is somebody fuzzing IPv6 autoconfiguration stacks? OpenBSD published an nd6 kernel fix earlier this month for an unrelated issue: https://ftp.openbsd.org/pub/OpenBSD/patches/7.8/common/011_n...

Having a shell script in the code path that processes router advertisements seems sub-optimal.

    vulnerable to remote code execution from
    systems on the same network segment

Isn't almost every laptop these days autoconnecting to known network names like "Starbucks" etc, because the user used it once in the past?

That would mean that every FreeBSD laptop in proximity of an attacker is vulnerable, right? Since the attacker could just create a hotspot with the SSID "Starbucks" on their laptop and the victim's laptop will connect to it automatically.

Oh that's a nasty one, embedded FreeBSD users will have a hard time mitigating this.

> no workaround

> IPv6 users that do not configure the system to accept router advertisement messages, are not affected.

Maybe I'm missing something but isnt that a workaround?

Can we be done with the house of cards that are shell scripts everywhere?

Anyways, this feels like a big issue for "hidden" FreeBSD installs, like pfSense or TrueNAS (if they are still based on it though). Or for servers on hosting providers where they share a LAN with their neighbors in the same rack.

And it's a big win for jailbreaking routers :D

IPv6 is a prerequisite for the bug to be exploited, it won't affect anyone.

is my understanding right?

"PC or computers or hardware that uses OS that consume FreeBSD, has a faulty software for the router's firmware?"

"The router's software performs ad distributions?"

"The version of internet, the router uses, is updated, whereas, the target machine, or the user's machine is still running a old version"

"The security patch works for the modern but not the precursor version?"

"This leaves older systems obsolete in the market?"

"is this a step-by-step instructions to business owners to introduce new products, selling that older products are obsolete" ?