FreeRADIUS fragged by fuzzer – by invitation – and fifteen fails found

Bug fixes shipped for all supported versions

The folks over at FreeRADIUS took a look at Guido Vranken's work with OpenSSL, liked what they saw, asked him to fuzz the famous login/security server ... and then didn't like what they saw.

Pretty much anybody who's logged into an ISP account has touched FreeRADIUS, since it's the most popular implementation of the venerable authentication system.

As this post explains, after Vranken disclosed bugs in OpenSSL, he tipped the FreeRADIUS maintainers of a similar (now fixed) bug in their project.

They followed up by asking him to conduct a joint project, and that turned up a haul of 15 issues, four of which could be exploitable, and one of which is a remote code execution bug (RCE).

The RCE, CVE-2017-10984, is a write overflow in the data2vp_wimax() function. In version 3 series of FreeRADIUS (not version 2), anyone who can send packets accepted by the server could trigger the overflow.

The post explains that the exploit vector is via WiMAX attributes “which have the 'continuation' flag set, but for which there is no subsequent data”.

Absent RCE, the post notes that the bug also offers a denial-of-service vector.

The post also highlights that the fuzzing project turned up six issues in DHCP that are fixed in FreeRADIUS, mostly related to memory handling errors that offered denial-of-service vectors.

Proper deployments should be at least moderately protected if they followed best practice, since the server should not be directly exposed to the Internet. That means attack vectors should only exist for insiders, or to members of roaming consortia.

Kaspersky's Threatpost quotes FreeRADIUS founder Alan DeKok as explaining the limited exploitability of the bugs: “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”.

Regardless, FreeRADIUS's disappointment is palpable in the post: “There are about as many issues disclosed in this page as in the previous ten years combined”, it states (italics preserved from original post).

A long program of static tests – the post name-checks Coverity, Clang analyser, cppcheck, and PVS-Studio – clearly hasn't been enough to turn up all the bugs, which arise because “C is a terrible language for security”.

“We will therefore be integrating the fuzzer into all future releases of the server. We will be updating our automated build system to run with memory sanitizers enabled. We strongly recommend that other software projects follow the same practices.” ®

Sponsored: Becoming a Pragmatic Security Leader

Biting the hand that feeds IT © 1998–2019