Earlier quoted context omitted.
If you run FreeBSD on your laptop you don't auto connect to public WiFi. Joking, but not that much :)
Your wifi chip probably isn’t supported tbh.
RCE via ND6 Router Advertisements in FreeBSD
21–30 of 85 posts
Re: RCE via ND6 Router Advertisements in FreeBSD
#22vulnerable 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 :)
Re: RCE via ND6 Router Advertisements in FreeBSD
#23Earlier 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.
Re: RCE via ND6 Router Advertisements in FreeBSD
#24Earlier quoted context omitted.
Free jailbreaks for everyone though!
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.
Re: RCE via ND6 Router Advertisements in FreeBSD
#25Earlier quoted context omitted.
If you run FreeBSD on your laptop you don't auto connect to public WiFi. Joking, but not that much :)
FreeBSD 15 had a massive improvement with WiFi, however if you let your Computer auto-connect to a "unknown" Network...well that's not good.
As far as I know, access points only identify via their SSID. Which is a string like "Starbucks". So there is no way to tell if it is the real Starbucks WiFi or a hotspot some dude started on their laptop.
Re: RCE via ND6 Router Advertisements in FreeBSD
#26Earlier quoted context omitted.
FreeBSD 15 had a massive improvement with WiFi, however if you let your Computer auto-connect to a "unknown" Network...well that's not good.
My question was about known networks. As far as I know, access points only identify via their SSID. Which is a string like "Starbucks". So there is no way to tell if it is the real Starbucks WiFi or a hotspot some dude started on their laptop.
Aka "unknown" or "public" Network....don't do that.
Re: RCE via ND6 Router Advertisements in FreeBSD
#27Can 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
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 featu…
Why not? And I don't mean this in tongue-in-cheek, but as a genuine interrogation: why not go the macOS/systemd route?
DNS is a complex topic. Much more complex than people admit it is, and that can definitely not be expressed fully with resolv.conf. I do agree that it is too late to get rid of it (and was not my concern actually), but it is too limited to be of actual use outside of the simple "I have a single DNS server with a single search domain". IMHO, a dedicated local daemon with its own bespoke config definitely has value, even if it solely provides a local cache for applications that don't have one already (like most of them outside of browsers). And for more complex cases, simple integration with the network configuration daemon provides actual value in e.g. knowing that a specific server is reachable through a specific interface that has a specific search domain. That is, native routing to the correct servers to avoid the timeout dance as soon as you have split networks.
Also, for the local ad-hoc configuration part. We already have nsswitch which is its own can of worms that pretty much nobody have ever heard about let even touched its configuration. Heck, I've written DNS servers but only looked once at nsswitch. resolved's configuration is integrated in the systemd ecosystem, has an approachable and well documented configuration, and is pretty useful in general.
Anyways, the main gripe I had was not really at the mess that is DNS on Linux, but the general stance in the UNIX-like world against anything that's not a lego of shell scripts because "that's not the unix philosophy". Yeah you can write an init system fully with sh, have their "units" also all be written in sh, but oh lord has stuff like systemd improved the situation for the init + service part. Having a raw string from a network packet land in a shell script is a recipe for disaster, seeing how much quoting in scripts is famously difficult.
> The problem with the new, alternative monoliths is they very quickly run off into the weeds with their crazy features and configuration
Agreed for the crazy features. systemd is a godsend for the modern linux world, but I'm skeptical when I see the likes of systemd-home. Yet the configuration is not where I'd pick at those systems though, because they tend to be much more configurable. They are opiniated, yes, but the configuration is an actual configuration and not a patchwork of shell scripts somewhere in /etc, when they're not direct patches to the foundational shell scripts!
> in ways that create barriers for userland applications
How so? In the specific example of resolved, I'd argue it's even less work for applications, because they don't need to query multiple DNS servers at once (it'll handle it for them), don't need to try resolution with and without search domain, etc.
In the end, I find that resolved's approach at symlinking its stub resolv.conf is the most elegant approach with our current setups.
PS: I talk a lot about resolved because that's the one I know best, not the one I think is the best! It has loads of shortcomings too, yet it's still a net improvement to whatever was in place before.
Re: RCE via ND6 Router Advertisements in FreeBSD
#28It 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!
Re: RCE via ND6 Router Advertisements in FreeBSD
#29Earlier quoted context omitted.
FreeBSD 15 had a massive improvement with WiFi, however if you let your Computer auto-connect to a "unknown" Network...well that's not good.
My question was about known networks. As far as I know, access points only identify via their SSID. Which is a string like "Starbucks". So there is no way to tell if it is the real Starbucks WiFi or a hotspot some dude started on their laptop.