11–20 of 85 posts
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 lapto…
Oh that's a nasty one, embedded FreeBSD users will have a hard time mitigating this.
Free jailbreaks for everyone though!
Earlier quoted context omitted.
Why, is IPv6 activation manual in FreeBSD?
It's enabled by default, I was mostly talking about being in a lan with active ipv6, imo that's not that common.
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 lapto…
If you run FreeBSD on your laptop you don't auto connect to public WiFi. 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
Earlier quoted context omitted.
It's enabled by default, I was mostly talking about being in a lan with active ipv6, imo that's not that common.
That's pretty standard where I am. Every Telstra router comes with IPv6 enabled.
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
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.