FreeRADIUS Update Patches Bugs Static Analysis Tools Missed

FreeRADIUS today released an update that patches a number of vulnerabilities uncovered in a commissioned engagement using a customer fuzzer.

FreeRADIUS, the popular open source RADIUS server, today published updates that include fixes for a number of security issues uncovered by a custom fuzzer built by Dutch researcher Guido Vranken.

Vranken used a custom version of libFuzzer to find a handful of serious bugs in OpenVPN that were ultimately patched in late June. A memory leak related to misuse of the OpenSSL API in OpenVPN was also found in and disclosed to FreeRADIUS, prompting the project to commission Vranken to take a closer look at the server software.

What he found were 15 vulnerabilities, nine in RADIUS (five of which are unexploitable, FreeRADIUS said) and six others in DHCP. Two of the RADIUS vulnerabilities are remote code execution bugs.

“That’s about as bad as it gets,” FreeRADIUS cofounder Alan DeKok said.

What also disappointed DeKok was that four commercial static analysis tools used since version 3 of the software failed to catch any of the bugs.

“The biggest disappointment for me was that the 4 static analysis tools are just inadequate. While they each found things, none of them found the errors found by fuzzing,” DeKok said. “It looks like static analysis tools are best at tracking issues found via complex program state. e.g. functions calling other functions. They are not that good at tracking complex data state, e.g. packet parsing.”

While some of the vulnerabilities are critical, exploiting them could be a challenge in most configurations, for example, if the RADIUS server is on a private network and accessible only by managed devices. FreeRADIUS cautions, however, that if the server is part of a roaming consortium or if it’s on the public internet—which is not recommended—then it can be attacked.

“To be clear: these issues aren’t exploitable by end users in any way. Even the roaming groups typically use IPSec or TLS to transport RADIUS traffic, which means they’re largely not vulnerable, either,” DeKok said. “The people who are vulnerable are the people who have their RADIUS servers on the public internet. That has always been a security problem, due to the design limitations of RADIUS.”

RADIUS servers are based on the RADIUS networking protocol that facilitates centralized authentication and authorization for users connected to network services. DeKok describes RADIUS’ security, from a design perspective, as “poor,” particularly because its Access-Request packets are not digitally signed.

“If they had been signed, the issues presented today would not be anywhere near as problematic,” DeKok said. “The standards have suggested that Access-Request packets be signed since 2007, when RFC 5080 was published. I was pushing for that since at least 2004, IIRC.

“I’m disappointed that most RADIUS vendors have not followed decade-old advice, and fixed their products to be compliant with RFC 5080,” DeKok continued. “Signing those packets is almost zero-cost: 18 bytes in a packet, one HMAC-MD5 calculation, maybe 20 lines of code. Yet 10 years on, I’m not aware of any RADIUS vendor (other than FreeRADIUS) which signs all Access-Request packets by default.”

Versions 2 and 3 are affected by the vulnerabilities, which are explained in detail in the FreeRADIUS advisory. Vranken’s fuzzer, meanwhile, will be integrated into future releases of FreeRADIUS, DeKok said.

Suggested articles