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.
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.
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!
> 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.
*/
12 comments
[ 2.4 ms ] story [ 23.9 ms ] thread"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" ?
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.
Google tracks IPv6 adoption at almost 50% globally and over 50% in the USA (https://www.google.com/intl/en/ipv6/statistics.html)
IPv6 is mainstream.
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
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!
> 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?
The fix consists of implementing an XXX present since the code was added:
https://www.freebsd.org/security/patches/SA-25:12/rtsold.pat...