Live data from Hacker News

RCE via ND6 Router Advertisements in FreeBSD

freebsd.org

41–50 of 85 posts

Re: RCE via ND6 Router Advertisements in FreeBSD

#41
post #28

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…

> We can only hope the firmware vendors are on top of their game.

You should go into comedy, this would kill at an open mic!

Re: RCE via ND6 Router Advertisements in FreeBSD

#42

> no workaround > 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?

"work-around" tends to imply you get to keep using things. By your logic, turning the computer off would be a work-around too.

Re: RCE via ND6 Router Advertisements in FreeBSD

#44
post #30

Having a shell script in the code path that processes router advertisements seems sub-optimal.

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.

I can't tell whether you're making a joke, seeing as the entire BSD init system is built on shell scripts.

Re: RCE via ND6 Router Advertisements in FreeBSD

#45
post #28

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…

> My HN addiction is now vindicated as I would probably not have noticed this RCE until after christmas.

Always makes sense to subscribe to the security-announce mailing list of major dependencies (distro/vendor, openssh, openssl etc.) and oss-security.

Re: RCE via ND6 Router Advertisements in FreeBSD

#46

Earlier quoted context omitted.

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.

I can't tell whether you're making a joke, seeing as the entire BSD init system is built on shell scripts.

Probably not a joke. In the same way people want to get away from the C language due to its propensity to memory vulnerabilities, shell scripts have their own share of footguns, the most common being a variable not being quoted when it should (which is exactly the issue described in this advisory).

It doesn't mean getting away from scripting languages; it means getting away from shell scripts in particular (the parent poster said specifically "zero shell scripts"). If the script in question was written in Lua, or heck even Javascript, this particular issue most probably wouldn't have happened, since these scripting languages do not require the programmer to manually quote every single variable use.

Re: RCE via ND6 Router Advertisements in FreeBSD

#47
post #46

Earlier quoted context omitted.

I can't tell whether you're making a joke, seeing as the entire BSD init system is built on shell scripts.

Probably not a joke. In the same way people want to get away from the C language due to its propensity to memory vulnerabilities, shell scripts have their own share of footguns, the most common being a variable not being quoted when it should (which is exactly the issue described in this advisory). It doesn't mean getting away from scripting languages; it means getting away from shell scripts in particular (the paren…

That's fine; I just thought it was weird to say that we should check to see whether any shell scripts are used in the BSD init system. We know there are; it was a deliberate design decision at the time, even if we might now wish for it to be different.

Re: RCE via ND6 Router Advertisements in FreeBSD

#48

Earlier quoted context omitted.

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.

I can't tell whether you're making a joke, seeing as the entire BSD init system is built on shell scripts.

Not a joke. I knew they used to use a pile of janky shell scripts for their init system. I didn't know they still do. That's disappointing.

And cesarb is correct - the issue isn't scripts; it's shell scripts, especially Bash and similar. Something like Deno/Typescript would be a decent option for example. Nushell is probably acceptable.

Even Python - while a terrible choice - is a better option than shell scripts.

Re: RCE via ND6 Router Advertisements in FreeBSD

#49
post #25

Earlier quoted context omitted.

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.

WPA2-entreprise and WPA3 both have certificate chains checking exactly to avoid such attacks

Hmm. Are you sure that your stack wouldn't accept these discovery packets until after you've successfully authenticated (which is what those chains are for) ?

Take eduroam, which is presumably the world's largest federated WiFi network. A random 20 year old studying Geology at Uni in Sydney, Australia will have eduroam configured on their devices, because duh, that's how WiFi works. But, that also works in Cambridge, England, or Paris, France or New York, USA or basically anywhere their peers would be because common sense - why not have a single network?

But this means their device actively tries to connect to anything named "eduroam". Yes it is expecting to eventually connect to Sydney to authenticate, but meanwhile how sure are you that it ignores everything it gets from the network even these low-level discovery packets?

Re: RCE via ND6 Router Advertisements in FreeBSD

#50
post #19

Earlier quoted context omitted.

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…

> Sure, as long as the solution isn't to just bolt on another distinct DNS monolith 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), bu…

Yet despite using systemd installing Tailscale on Manjaro and other Linux’s still can’t handle integrating with MagicDNS without some hackery.

So far tailscale magicdns just works on FreeBSD.

I second that systemd is great, for services. Anything beyond that? Just a gargantuan opaque buggy overreach.

Post reply on HN