Brutkey

Fritz Adalis
@FritzAdalis@infosec.exchange

So ISC DHCP is apparently end of life, replaced by #Kea. Looks neat on the surface, I figured let's take a look.
My gateway runs
#OpenBSD, but the Kea port is a little bit old. How hard could it be to roll a couple of version numbers? So I set up a vm to build and test.

Okay, so it turns out they completely changed the build process between 2.x and 3.0, to Meson. It seems to do both configure and make. Gotta update the port and learn how to deal with Meson. I'm sure it's wonderful.

Only ran into one real porting issue. Apparently OpenBSD does something different with bpf_timeval, and it's a different type? And Boost doesn't know how to convert it. Fortunately this was already a problem in nmap and worked around, so I copied the workaround.

Wait. Bpf? Nmap? Why does a dhcp server have its own network stack?!

Anyway I get it to compile and start to look at the installation part. That's when it dawns on me: THEY RUN EVERYTHING AS ROOT IN THE YEAR OF OUR LORD TWENTY TWENTY-FIVE.

They split each section of the server into its own process, it'd be perfect for a least-privilege bind-ports-and-drop-privs model with everything as a different user. They do fuzzing as part of the build! They set LIBCPP_HARDENING_MODE! Well, they set it to FAST which only does like two checks but at least they set it!

And how about that, they recently posted a couple of LPE vulnerabilities that wouldn't have worked without root. (Should have checked that first...) I suspect there will be more.

Note: I did see their instructions for running as non-root. It's a completely manual process that only works on Linux (by assigning capabilities). Everything still runs as the same user, and that user has CAP_BIND_RAW. It's also not the default and literally zero people will do this.

/rant


Michael Dwyer
@mdwyer@mastodon.social

@FritzAdalis@infosec.exchange

Why does a dhcp server have its own network stack?!
That's sort of expected for DHCP. It needs to talk to devices that don't yet have an address, and it does that by assembling bespoke packets. That's a dangerous privilege that's properly restricted.

This lead to one of the most exciting events of my career. That one time US-EAST-1 didn't crash? That was me!
😁😁

Maybe DHCP should be a kernel service, like ARP? That's a chilling thought...

Fritz Adalis
@FritzAdalis@infosec.exchange

@mdwyer@mastodon.social
You were the one that prevented US-EAST-1 from crashing? Nice! My saves are on a much smaller scale.

I'll begrudgingly concede that it needs to generate its own packets so it needs its own stack. I'd still be happier if they limited that priv to just a small subprocess and then dropped it for everything else. And if they did it in a way that wasn't Linux-specific.

Michael Dwyer
@mdwyer@mastodon.social

@FritzAdalis@infosec.exchange
Well, let's be honest: everyone's job there was keeping US-EAST-1 from crashing...

But, yeah I take your point. It is an interesting thought. I'm even seriously mulling the kernel idea. Is there a minimal stub you could put in the kernel and leave all the scary stuff in user space?

This wouldn't help the BSD case at all, of course.

But that same minimal stub could be the portion you run as root.

Does PING still require setuid?

Fritz Adalis
@FritzAdalis@infosec.exchange

@mdwyer@mastodon.social
Looks like on OpenBSD it is, but it opens the raw socket and drops privs to the calling user, plus pledge and unveil.