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

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

http://ift.tt/2vw1g25

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.” ®

TECH|SCI

via The Register – Security http://ift.tt/2jCNZ5O

July 17, 2017 at 09:36PM

Advertisements

What do you think about this?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s