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.
We had a soccer player in NL that was wildly popular and he had these funny remarks every now and then which got him nicknamed the most well known dutch philosopher. One of these was 'every advantage has its disadvantage', I guess this is one of those.
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.
IMHO you do not need "active" IPv6. Most LANs (unless you have some switch-level filtering that blocks router advertisements from "unauthorized" nodes) can transport such IPv6 packets. Then it just takes being connected to the LAN and being able to send an arbitrary ICMP6 packet (which probably means being root on the attacker machine, not a very high barrier I'd say).
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.
That was my first thought, if this is an embedded system without an update path this will be super hard to solve. People usually are not even aware of what OS their appliances run under the hood and whether or not they are updated automatically and how to update them if they are not.
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.
Joking, but not that much :)
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'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.
"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" ?
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.