Local vulnerabilities in Kea DHCP

[Posted May 29, 2025 by jzb]

The SUSE Security Team has published a detailed report about security vulnerabilities it discovered in the Kea DHCP server suite from the Internet Systems Consortium (ISC).

Since SUSE is also going to ship Kea DHCP in its products, we performed a routine review of its code base. Even before checking the network security of Kea, we stumbled over a range of local security issues, among them a local root exploit which is possible in many default installations of Kea on Linux and BSD distributions. [...]

This report is based on Kea release 2.6.1. Any source code references in this report relate to this version. Many systems still ship older releases of Kea, but we believe they are all affected as well by the issues described in this report.

The report details seven security issues including local-privilege-escalation and arbitrary file overwrite vulnerabilities. Security fixes for the vulnerabilities have been published in all of the currently supported release series of Kea: 2.4.2, 2.6.3, and the 2.7.9 development release were all released on May 28. Kea has assigned CVE-2025-32801, CVE-2025-32802, and CVE-2025-32803 to the vulnerabilities. Note that some of the CVEs cover multiple security flaws.

Thanks to the SUSE team!

Posted May 29, 2025 18:50 UTC (Thu) by tbleher (guest, #48307) [Link]

Thanks a lot to the SUSE team for the detailed analysis and the writeup! Not only did they analyze the software itself, they also looked at how various distributions install the software, and which mitigations they have in place (e.g. AppArmor). A great example to follow.

Kea

Posted May 29, 2025 19:00 UTC (Thu) by job (guest, #670) [Link] (12 responses)

Kea always struck me as having a bit of second system syndrome from dhcpd. It was in development for a long time and is somewhat complex.

Kea

Posted May 30, 2025 13:11 UTC (Fri) by Sesse (subscriber, #53779) [Link] (11 responses)

It's also a bit sad how many things are gone from ISC dhcpd; deprecating dhcpd before Kea has full feature parity leaves some users in a bit of a bind.

I agree that Kea is overly complex; it fixes an issue almost nobody has (performance in installation with 100k+ nodes) in exchange for a bazillion daemons and a codebase that takes ages to compile even on my 5950X.

Kea

Posted May 30, 2025 14:35 UTC (Fri) by zdzichu (subscriber, #17118) [Link] (1 responses)

> it fixes an issue almost nobody has (performance in installation with 100k+ nodes)

That's why Meta ❤️ Kea.

> a bazillion daemons

Where?

CGroup: /system.slice/kea-dhcp4.service
└─3797 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf

Kea

Posted May 30, 2025 14:40 UTC (Fri) by Sesse (subscriber, #53779) [Link]

dhcp4-server, dhcp6-server, dhcp-ddns, the control agent, and then some additional stuff for Stork (agent and server, IIRC) if you want to set up basic stats. And all of this needs to talk over sockets that have to be configured and by default are not very well secured.

Kea

Posted May 30, 2025 14:51 UTC (Fri) by DemiMarie (subscriber, #164188) [Link] (7 responses)

Also Kea is clearly latency-bound rather than throughput-bound when it comes to backend storage, which tells me there were design mistakes. A solution that is asynchronous and properly batches storage operations should be able to achieve much higher throughput.

Kea

Posted May 30, 2025 14:54 UTC (Fri) by Sesse (subscriber, #53779) [Link] (6 responses)

Is this with the CSV backend? (Or: What is it that you're doing with Kea that's putting so much demand on your storage?)

Kea’s missing transaction batching

Posted May 31, 2025 19:44 UTC (Sat) by DemiMarie (subscriber, #164188) [Link] (5 responses)

What I mean is that any database should be able to handle thousands of operations per second, provided that the client performs transactions in batches so that per-transaction overheads (such as network and fsync() latency) are amortized across the entire batch. A DHCP server could be designed to take advantage of this by submitting an entire batch of DHCP transactions to the database at once. While the database is performing its operation, accumulate the next batch of transactions. When the database operation finishes, submit the next batch and send acknowledgements for the first batch. Repeat as long as there are events.

The documentation at https://kb.isc.org/docs/kea-performance-optimization is clear that external lease file backends are expensive, so presumably there are users for which this is a problem. External lease file backend would not be a performance problem in a system that operates as I described above: they would only impact latency, not throughput.

Kea’s missing transaction batching

Posted May 31, 2025 20:07 UTC (Sat) by Sesse (subscriber, #53779) [Link] (4 responses)

OK, so you're basically asking that Kea buffer up changes and submit them all within one SQL transaction to the database backend? It sounds like something that is normally done in the database level (i.e., grouping fsyncs), but of course, that requires Kea to expose some parallelism as you say. (Either through async, or using more threads.) Anything else is fairly complex, as I believe Kea would want the lease commit to go through before it actually sends out the DHCPACK? (I haven't checked, I'm fine with memfile.)

Kea’s missing transaction batching

Posted Jun 1, 2025 4:37 UTC (Sun) by DemiMarie (subscriber, #164188) [Link] (3 responses)

You are correct that the commit should happen before sending DHCPACK, but that’s easy to ensure by buffering the DHCPACK packets until the whole batch of transactions has committed. In theory, databases should do the batching you describe, but I believe at least PostgreSQL can’t due to internal limitations.

Kea’s missing transaction batching

Posted Jun 1, 2025 7:32 UTC (Sun) by Sesse (subscriber, #53779) [Link] (2 responses)

In Postgres, commit_delay governs this behavior.

Kea’s missing transaction batching

Posted Jun 1, 2025 11:40 UTC (Sun) by andresfreund (subscriber, #69562) [Link] (1 responses)

And batching happens even without that setting, if multiple transactions start to flush while another flush is in progress.

PostgreSQL parallelism

Posted Jun 2, 2025 18:59 UTC (Mon) by DemiMarie (subscriber, #164188) [Link]

Does PostgreSQL support processing multiple transactions in parallel? Can it issue writes and reads with the high queue depths needed to get optimum performance out of modern storage?

Kea

Posted Jun 3, 2025 4:13 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Yeah, dhcpd was battle tested and worked fine, although more complex configurations were ... complex, and I'm not sure it's bespoke config syntax is better than just using JSON like Kea. Unfortunately for me I _do_ have one of those sites with 100k+ clients, and while HA dhcpd worked OK in normal circumstances, if there is any network instability and clients have to retry it can become overwhelmed at that scale, peg 100% CPU on the single core it runs on, and your network doesn't work which makes for a lot of unhappy people. Kea seems to have about 10x higher limits on performance, the fact its not higher is probably related to locking since it's still managing one shared datastructure but I don't have enough CS background or time to figure it out exactly, but I'm sure the smarties at ISC did something reasonable.

I imagine the Enterprise distros that shipped dhcpd in their last release will continue to maintain it for the next 5+ years, and it's not as if there should be a ton of maintenance in such a mature codebase.

From the ISC web site

Posted May 29, 2025 20:54 UTC (Thu) by bferrell (subscriber, #624) [Link] (11 responses)

ISC has developed a new DHCP server, Kea, which we intend to replace ISC DHCP in most server implementations. We recommend that new implementers use Kea and implement ISC DHCP only if Kea does not meet their needs. The Kea distribution does not currently include either a client or a relay. Anyone interested in underwriting the development of a DHCP client or relay is encourage to contact ISC at info@isc.org.

So... Suse selected a not yet complete project and wrote up the flaws.

The good news is that dhcpcd (used mostly in debian based distros at one time) wasn't used by default. I've not done a modern deb install in a while so it may still be in use.

I spent a full 36 hours troubleshooting an odd behavior... If ISC dhcp is set to send extra routes, the last extra route ends up the default route for dhcpcd. A lot of fiddling with ISC dhcpd will get dhcpcd to work right... But then it breaks dhcp in iphones, android devices, "smart" plugs and Windows.

The machines that caused me to look into it (raspberry pi) got dhcpcd yanked and the ISC dhcp client installed.

Yes, I DID discuss it with the dev and gave up. It does faithfully support an obscure RFC. But the RFC is broken (as far as I'm concerned).

From the ISC web site

Posted May 29, 2025 21:23 UTC (Thu) by rschroev (subscriber, #4164) [Link] (9 responses)

The other text on the page were you got that is:

"ISC has announced the end of maintenance for ISC DHCP as of the end of 2022. ISC will continue providing professional support services for existing subscribers, but does not intend to issue any further maintenance releases. For resources that may help in migrating your existing ISC DHCP server deployment to our newer DHCP server, Kea, please see this page.

ISC DHCP was a complete open source solution for implementing DHCP servers, relay agents, and clients."

Clearly the ISC really wants you to use Kea instead of ISC DHCP server. You don't want to run network software that hasn't been maintained since 2022.

It does feel weird that ISC doesn't have a client or relay agent anymore. Did people migrate to other solutions?

From the ISC web site

Posted May 30, 2025 9:43 UTC (Fri) by jengelh (guest, #33263) [Link]

>Did people migrate to other solutions?

I migrated to IPv6/SLAAC :-p
NetworkManager has its own client. And some people might have gone with udhcp or systemd-networkd.

From the ISC web site

Posted May 30, 2025 10:08 UTC (Fri) by joib (subscriber, #8541) [Link] (4 responses)

There's dhcpcd (used in Ubuntu initramfs, presumably Debian and other Debian-based distros as well). Not sure what other distros are using for initramfs needs. And NetworkManager as well as systemd-networkd have their own internal clients, which I guess is what most distros are using by default.

I'm not aware of any maintained open source relay agent. One particular brand of switches I'm aware of hasn't migrated off isc dhcp relay, presumably the vendor is supporting it themselves.

From the ISC web site

Posted May 30, 2025 16:46 UTC (Fri) by auerswal (subscriber, #119876) [Link] (1 responses)

Dnsmasq (https://dnsmasq.org/doc.html) contains DHCP relay functionality, is available under the GPL, version 2 or version 3, and maintained.

From the ISC web site

Posted May 30, 2025 18:38 UTC (Fri) by joib (subscriber, #8541) [Link]

Oh! I'm familiar with dnsmasq, but I didn't realize it provides dhcp relay functionality as well. Thanks!

From the ISC web site

Posted Jun 1, 2025 13:18 UTC (Sun) by bferrell (subscriber, #624) [Link] (1 responses)

from my previous post:

The machine that prompted me to investigate (a Raspberry Pi) had dhcpcd removed and the ISC DHCP client installed.

Yes, I DID discuss it with the dev and gave up. It does faithfully support an obscure RFC. But the RFC is broken (as far as I'm concerned).

From the ISC web site

Posted Jun 2, 2025 15:18 UTC (Mon) by hmh (subscriber, #3838) [Link]

This is interesting... can you post some details? a link to a bug report, or the reference to the "obscure RFC", etc ?

From the ISC web site

Posted May 30, 2025 13:13 UTC (Fri) by Sesse (subscriber, #53779) [Link]

I believe you can use Kea itself as a relay agent (though not a client).

OpenBSD dhcpd?

Posted May 30, 2025 14:52 UTC (Fri) by DemiMarie (subscriber, #164188) [Link]

Is that still maintained?

From the ISC web site

Posted Jun 4, 2025 0:02 UTC (Wed) by fratti (guest, #105722) [Link]

> Clearly the ISC really wants you to use Kea instead of ISC DHCP server. You don't want to run network software that hasn't been maintained since 2022.

You are talking to a Debian user. They only run software that hasn't been maintained since 2022.

From the ISC web site

Posted May 30, 2025 18:33 UTC (Fri) by gherkin (guest, #177675) [Link]

There's quite a lot of interesting background/historical info on the ISC site, touching on both Kea and ISC DHCP, and their history, for example the blog article announcing the EoL for ISC DHCP (https://www.isc.org/blogs/isc-dhcp-eol/) - which points to a lot of the reasons why Kea was developed, and notes the following from one of the ISC DHCP maintainers:

"The relay was never really popular - people mostly used their ethernet switches features for relaying - but it provided value by being a “tool in the toolbox” so to speak, useful in a pinch."

And the relay and client functionality was EoL'd from ISC DHCP about a year and a half before the rest of the project, so it's perhaps understandable that ISC saw little demand for that functionality in Kea from their sponsors and other funding sources.

https://www.isc.org/dhcphistory/ was interesting too, particularly Kea's origins in BIND 10.

(Given the links to BIND 10, and that era at ISC, I'd suspect that there are probably some fun bits of history that didn't make it past the PR machine ;) )