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!
Even better, the reboot wasn't needed as the kernel didn't get bumped on this one. Just restart the rtsold service if you're using it and sanity check your resolv.conf and resolvconf.conf.
As for noticing it quickly, add `freebsd-update cron` to crontab and it will email you the fetch summary when updates are available
> 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.
*/
It is wild that it was in that state for so long. It probably took just about as long to write that comment as it would have to implement the proper solution.
It's amazing the number of people that thing shell scripts should be anything other than throwaway single-person hacks.
They should probably go through their whole system and verify that there aren't more shell scripts being used, e.g. in the init system. Ideally a default distro would have zero shell scripts.
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.
Sure, as long as the solution isn't to just bolt on another distinct DNS monolith. The root of the problem IMO is that no libc, AFAIK, exports an API for parsing, let alone composing or manipulating, resolv.conf formatted data. The solutions have either been the same as FreeBSD (openresolv, a portable implementation of Debian's resolvconf tool), or just freezing resolv.conf (notwithstanding occassional new libc features) and bolting atop (i.e. keeping in place) the existing infrastructure a monolithic resolver service with their own bespoke configs, such as macOS and Linux/systemd have done. But resolv.conf can never go away, because it's the only sane and portable way for your average userland program to load DNS configuration, especially async resolver libraries.
It's a coordination problem. Note that the original notion of resolvconf, IIUC, was it was only stitching together trusted configuration data. That's no excuse, of course, for not rigorously isolating data from execution, which is more difficult in shell scripts--at least, if you're not treating the data as untrusted from the get go. It's not that difficult to write shell code to handle untrusted data, you just can't hack it together without keeping this is mind. And it would be much easier if the resolver infrastructure in libc had a proper API for dealing with resolv.conf (and others), which could be exported by a small utility which in turn could be used to slice and dice configurations from shell scripts.
The problem with the new, alternative monoliths is they very quickly run off into the weeds with their crazy features and configuration in ways that create barriers for userland applications and libraries to rely upon, beyond bootstrapping them to query 127.0.0.1:53. At the end of the day, resolv.conf can never really go away. So the proper solution, IMO, is to begin to carefully build layers around the one part that we know for a fact won't go away, rather than walking away with your ball to build a new playground. But that requires some motivated coordination and cooperation with libc developers.
No, I don't think you are understanding this right, but there are some good questions you are asking. Where is the flag button?
If you are a real human, the most interesting question you're bringing up is What about all the appliances backed by FreeBSD? Yes, they are obsolete if they use IPv6 and accept RAs and if they don't get updates.
clan|2 months ago
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!
barnas2|2 months ago
You should go into comedy, this would kill at an open mic!
cornonthecobra|2 months ago
As for noticing it quickly, add `freebsd-update cron` to crontab and it will email you the fetch summary when updates are available
formerly_proven|2 months ago
Always makes sense to subscribe to the security-announce mailing list of major dependencies (distro/vendor, openssh, openssl etc.) and oss-security.
elcritch|2 months ago
bah_humbug|2 months ago
The fix consists of implementing an XXX present since the code was added:
https://www.freebsd.org/security/patches/SA-25:12/rtsold.pat...jandrese|2 months ago
apstls|2 months ago
wahern|2 months ago
chaz6|2 months ago
IshKebab|2 months ago
They should probably go through their whole system and verify that there aren't more shell scripts being used, e.g. in the init system. Ideally a default distro would have zero shell scripts.
TekMol|2 months ago
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.
francasso|2 months ago
Joking, but not that much :)
hhh|2 months ago
jacquesm|2 months ago
formerly_proven|2 months ago
crest|2 months ago
tuetuopay|2 months ago
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
wahern|2 months ago
It's a coordination problem. Note that the original notion of resolvconf, IIUC, was it was only stitching together trusted configuration data. That's no excuse, of course, for not rigorously isolating data from execution, which is more difficult in shell scripts--at least, if you're not treating the data as untrusted from the get go. It's not that difficult to write shell code to handle untrusted data, you just can't hack it together without keeping this is mind. And it would be much easier if the resolver infrastructure in libc had a proper API for dealing with resolv.conf (and others), which could be exported by a small utility which in turn could be used to slice and dice configurations from shell scripts.
The problem with the new, alternative monoliths is they very quickly run off into the weeds with their crazy features and configuration in ways that create barriers for userland applications and libraries to rely upon, beyond bootstrapping them to query 127.0.0.1:53. At the end of the day, resolv.conf can never really go away. So the proper solution, IMO, is to begin to carefully build layers around the one part that we know for a fact won't go away, rather than walking away with your ball to build a new playground. But that requires some motivated coordination and cooperation with libc developers.
VoidWhisperer|2 months ago
> 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?
swills|2 months ago
wmf|2 months ago
rs_rs_rs_rs_rs|2 months ago
ale42|2 months ago
jrmg|2 months ago
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.
imvetri|2 months ago
"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" ?
eptcyka|2 months ago
If you are a real human, the most interesting question you're bringing up is What about all the appliances backed by FreeBSD? Yes, they are obsolete if they use IPv6 and accept RAs and if they don't get updates.