2024.07.09BlastRADIUS Vulnerability

Researchers at the University of California, San Diego have published an exploit for the RADIUS protocol. While attacks on MD5 have been known for a while, people only suspected that those attacks could be used against RADIUS. Their paper, or is the first time that a practical attack has been demonstrated.

The attack is due to a fundamental design flaw of the RADIUS protocol. It is not a flaw in any particular implementation or product. All standards compliant RADIUS clients and servers are likely vulnerable to this attack, even if they correctly implement all aspects of the RADIUS protocol.

We have worked with Nadia Heninger and her team to characterise the issue. We have written an engineering white paper which is available on our InkBridge Networks corporate site. This paper was used as the guide by all RADIUS vendors for how to fix the problem. The updates to the RADIUS standards. are mandating these changes in all future implementations of RADIUS.

For vendors, we strongly suggest reading that paper before implementing any solution. Our paper has been reviewed by the researchers, and they agree that the attack is not possible when our recommendations are followed. If a vendor implements any other solution, they are likely to remain vulnerable to the attack

There is also have a high-level FAQ available, along with upgrade documentation and tools available on InkBrigeNetworks.com web site. That company is the new name for Network RADIUS, which is the company behind FreeRADIUS.

The truly sad thing is that we’ve been trying to fix this issue since 1998. The first public record we can find of anyone complaining about this issue is by Alan DeKok (FreeRADIUS founder) in 1998. Alan further tried to fix it in RFC 5080, Section 2.2.2, in 2007.

FreeRADIUS has implemented those suggestions since 2005. If everyone had followed these suggestions, then this issue would not exist.

The big question for network administrators, then, is what to do.

What to do

In short, don’t panic. Even if you don’t upgrade your NAS equipment, the attack is expensive, and hard to perform. The odds of you being attacked in the next little while are small, but non-zero. You will need to upgrade, but you don’t want to upgrade in a panic, get something wrong, and take your entire network down. Take your time, plan the upgrade carefully, test the upgrade, and be sure that your network both works, and is safe.

The attack is hard, because it is a “man in the middle” attack, which means that the attacker has to be able to both see, and modify Access-Request packets. If the attacker can do that, then your network is already compromised.

Even better, the attack requires substantial CPU resources to do i.e. $1000 of CPU power per packet being attacked, and the attack isn’t even guaranteed. There is also no public exploit available for “script kiddies” to run. It is extremely unlikely that anyone other than nation-states have the capability to perform the attack at this time.

However, if you are running PAP / CHAP / MS-CHAP and RADIUS/UDP over the Internet, then your users have likely been compromised for decades. There is little more we can say about that.

In order to fully protect your systems from the attack, you must update all RADIUS servers, and all RADIUS clients. The attack relies on a design flaw in the protocol. Fixing it requires updating all RADIUS implementations to the new behavior. In many cases, you do not need to panic and upgrade everything immediately. See below for more details.

Even considering the limited nature of the attack, everyone should plan on installing all firmware updates for each NAS device (including switches, routers, firewalls, VPN concentrators, etc.) which uses RADIUS. The important thing in the short term is to upgrade the RADIUS servers, determine if your network is still vulnerable, and then take action to address those vulnerabilities.

Pre-built packages of FreeRADIUS are available on the corporate site at packages.networkradius.com.

How this attack impacts FreeRADIUS.

The biggest recommendation we have is to not panic and try to upgrade all of the NAS equipment. There is a high likelihood that something will go wrong. Instead, concentrate on upgrading the RADIUS servers first.

The simple checklist for testing your local vulnerability status is as follows:

• Is all RADIUS traffic accounting, and only accounting? The attack doesn’t affect you. You still need to upgrade everything, but you can take your time.

• Are all Access-Request packets sent over RADIUS/TLS (RadSec)? The attack doesn’t affect you. You still need to upgrade everything, but you can take your time.

• Are the RADIUS servers only doing EAP authentication, and no other kinds of authentication? The attack doesn’t affect you. You still need to upgrade everything, but you can take your time.

• Are the RADIUS servers only handling local requests? I.e. none of the RADIUS servers in your network are doing proxying? Upgrade FreeRADIUS, and then you are protected. You still need to upgrade the NAS equipment, but you can take your time.

Otherwise, if your system uses PAP, CHAP, or MS-CHAP over RADIUS/UDP, you need to upgrade FreeRADIUS, and then reconfigure it with the new configuration flags. In many cases, you can take your time to upgrade the NAS equipment.

New Configuration Options

In order to prevent the attach while still not breaking things, we have added two new configuration options to the security subsection of the radiusd.conf file. Simply upgrading will not set these flags, and upgrading will not affect production networks.

The first, and most important step is to upgrade FreeRADIUS. If the checks above show that your system is vulnerable, then upgrade immediately.

Once the system is upgraded, you can set the new configuration flags. See the security { ... } subsection of radiusd.conf. The default configuration on new systems (not your current radiusd.conf) has documentation on these flags.

The simplest and easiest thing for administrators to do is to edit the security section, and add the following two entries:

security {
    ...
    require_message_authenticator = auto
    limit_proxy_state = auto
}

Setting these flags will automatically protect most systems from the attack. The only systems which are not protected are ones where there are multiple different pieces of NAS equipment behind a NAT. In that case, the only solution is to upgrade all of those pieces of NAS equipment.

Setting these flags to auto will protect the overwhelming majority of systems. The worst outcome of setting these flags is that on some unusual network configurations, packets from real clients may be discarded, or packets from some clients may still be vulnerable to the attack.

Most regular RADIUS clients do not send Proxy-State attributes for Access-Request packets thatwhich they originate. However some aggregators (e.g. Wireless LAN Controllers) may act as a RADIUS proxy for requests from their cohort of managed devices, and in such cases they will provide a Proxy-State attribute. For those systems, you must look at the actual packets to determine what to do. It may be that the only way to fix the vulnerability is to upgrade the WLC, and set require_message_authenticator=true.

This article cannot provide a full description of how to upgrade all possible networks. There are simply too many different possible network architectures for a short guide to be helpful to everyone. We believe hat the above comments will help the vast majority of organizations to upgrade quickly, easily, and with minimal risk.

There is commercial BlastRADIUS help and tools available from InkBridge Networks (previously Network RADIUS). That page provides vendor-neutral upgrade documentation and test tools, which can be used on Windows, OSX, and Linux. The documentation and test tools will work with any RADIUS client or server.

If You Cannot Update

If you cannot update FreeRADIUS immediately, there are still changes you can make which should help to protect your systems. These changes will work in all versions of FreeRADIUS from 2.0.0 to the latest 3.2.4. Unfortunately, earlier versions of the server are unsupported, and should not be used.

These changes should ONLY be made for systems which cannot be updated.

If the RADIUS client is a proxy server, and the client is another copy of FreeRADIUS 3.0.0 or later, then there are simple steps you can take. You should be able to set the require_message_authenticator flag in the client definition for of the server which receives the Access-Requests. This flag is available in all versions of FreeRADIUS from 3.0.0 onwards, and has the same functionality as mandated by the updated RFCs.

If it is possible to set this flag for all clients, then your system is safe, and there is nothing more for you to do right now.

For systems accepting packets from a NAS, edit each virtual server which handles Access-Request packets, and look for the authorize section, and add the following “if” and “update” text at the top of that section:

authorize {
	if (!EAP-Message) {
		update reply {
			Message-Authenticator := 0x00
		}
	}
...

Then restart the server for the configuration change to take effect. This change will cause the server to include a Message-Authenticator in all responses to Access-Request packets. Depending on the rest of the local policies, the Message-Authenticator should then be the first attribute in Access-Accept, Access-Reject, and Access-Challenge responses. This change is safe to make, and will not affect any other behavior.

If the system is proxying Access-Request packets, then you need to make another change.

Look for the pre-proxy section, and add the following “if” and “update” text at the top of that section. Note that the “if” statement must appear all on one line, and should not be split across multiple lines.

pre-proxy {
	if ((Packet-Type == Access-Request) && !EAP-Message) {
		update proxy-request {
			Message-Authenticator := 0x00
		}
	}
	...

Then restart the server for the configuration change to take effect. This change will cause the server to include a Message-Authenticator in all proxied Access-Request packets. Depending on the rest of the local policies, the Message-Authenticator should then be the first attribute in those packets. This change is safe to make, and will not affect any other behavior.

The only way to add further protection is to upgrade the RADIUS server to the most recent version, and to follow the instructions above for setting require_message_authenticator and limit_proxy_state.

Further FreeRADIUS Documentation

The default radiusd.conf file contains comments which document these options, and describe how they work. Please consult that file for a more complete explanation.

Vulnerable Versions

As this is a vulnerability in the protocol, all versions of FreeRADIUS are vulnerable. We have supplied pre-built packages for 3.0.27, and 3.2.5.

There are no patches availalbe for version 2, version 1, or earlier versions of the server. Those products have been deprecated for over a decade, and are all marked “end of life”.

If you are still running an older version, the short-term fix is to update the configuration to add Message-Authenticator as the first attribute in all Access-Accept, Access-Reject, and Access-Challenge packets. We do not describe how to do that here.

The correct long-term fix for people running deprecated versions of the server is to upgrade to a supported version.

2022.04.22Information leakage in EAP-PWD

The EAP-PWD function compute_password_element() leaks information about the password which allows an attacker to substantially reduce the size of an offline dictionary attack.

The issue was found by Mohamed Sabt and his team at the University of Rennes.

Similar issues were found and fixed in hostapd and iwd.

The issue was fixed in commit 9e5e8f2f.

2022.04.22Crash on unknown option in EAP-SIM

When an EAP-SIM supplicant sends an unknown SIM option, the server will try to look that option up in the internal dictionaries. This lookup will fail, but the SIM code will not check for that failure. Instead, it will dereference a NULL pointer, and cause the server to crash.

All versions of FreeRADIUS from 0.9.3 to 3.0.25 which have the EAP-SIM module manually configured are affected.

The EAP-SIM module is not enabled in the default configuration. There is no sample configuration for the module, and no documentation on how to get it to work.

As a result, we expect that few sites are affected by this issue.

Any site which has configured EAP-SIM is vulnerable. Any malicious EAP-SIM peer can crash the server. No other actions other than the crash are possible.

This issue was found by Shane Guan, and reported to the freeradius-users mailing list.

The issue was fixed in commit f1cdbb.

2022.04.22Crash on invalid abinary data

A malicious RADIUS client or home server can send a malformed abinary attribute which can cause the server to crash.

All versions of FreeRADIUS from 0.0.1 to 3.0.25 are affected.

This crash is not exploitable by end users. Only systems which are in the RADIUS circle of trust can send these malformed attributes to a server. No actions other than a crash are possible.

As a result, the severity of this issue is low. A malicious RADIUS client or home server can do many worse things than crash the server. For example, it could cause all users to be authenticated, or cause all users to be rejected, or it could lie about all accounting data.

This issue was found during automated fuzzing of the source code.

The issue was fixed in commit 0ec2b39.

2021.12.16FreeRADIUS is NOT affected by the log4j issues

CVE-2021-44228

FreeRADIUS is not affected by the log4j issues.

However, RADIUS servers will try to authenticate any user who tries to connect. And the User-Name field is under complete control of an attacker. If any of the RADIUS logs go through a system which uses log4j, then your site is likely vulnerable.

We do not recommend changing the RADIUS server configuration in order to try to “work around” the log4j issue. The best solution is to fix the underlying problem.

2019.05.25Logrotate Issues

CVE-2019-10143

We disagree with this CVE. In the GitHub report [1], the RedHat reporter claims:

we are aware of a way to exploit this,

No description of this alleged exploit was shared with us at our security contact.

Our security contact is “security@freeradius.org”, which has been active for almost 20 years. This address and security instructions are available on our web site at:

https://freeradius.org/security/

In the GitHub report, RedHat further claims that exploitation

… requires the attacker to already have “high privileges” (that is, he needs to have access to the radiusd user)

Which demonstrates that this issue is largely nonsense. A full explanation follows.

While the FreeRADIUS server runs as user/group “radiusd/radiusd”, that account has no login shell, no home directory, and no default password. The account is used solely to run the FreeRADIUS server, and to control ownership of configuration files and log files. These files are typically administered solely by the “root” user.

As such, the CVE can be better stated as “if the root user misconfigures FreeRADIUS, then the RADIUS server can later elevate privileges to root”.

We have to ask why the “root” user would need to leverage a less-privileged account in order to gain “root” permissions.

Further, anyone who can operate as the RADIUS server can perform all RADIUS authentication and authorization. i.e. authenticating all users on the network, including unknown and malicious users.

There is at this time no known exploit which would let malicious users gain access to the “radiusd” user. Therefore as discussed here, there is simply no way for anyone to gain privileges through this alleged issue.

In addition, there also appears to be disagreement within RedHat about the severity and scope of this issue. The original reporter [2] states:

The su directive to logrotate ensures that log rotation happens under the owner of the logs. Otherwise, logrotate runs as root:root, potentially enabling privilege escalation if a RCE is discovered against the FreeRADIUS daemon.

This attack avenue seems quite unlikely to me.

We agree. We take great care in securing FreeRADIUS. We use multiple source code analyzers and fuzzing tests.

Even the most charitable interpretation of this issue shows that the vulnerability is theoretical in nature, and is not currently exploitable.

As such, we disagree with the issuance of this CVE. We also express dismay at the process by which this CVE was issued. We recommend that security “experts” follow best practices in discussing issues with authors prior to requesting spurious CVEs.

[1] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issuecomment-495511510 [2] https://github.com/FreeRADIUS/freeradius-server/pull/2666#issue-276755666

2019.04.10Authentication bypass in EAP-PWD

The EAP-PWD module is vulnerable to multiple issues, including authentication bypass. This module is not enabled in the default configuration. Administrators must manually enable it for their server to be vulnerable. Version 3.0.0 through 3.0.18 are are affected.

The EAP-PWD module is vulnerable to side-channel and cache-based attacks. The issue is discussed in more in Hostap 2019-2. The attack requires the attacker to be able to run a program on the target device. This is not commonly the case on an authentication server (EAP server), so the most likely target for this would be a client device using EAP-PWD. It is not clear at this time if the attack is possible between multiple virtual machines on the same hardware.

Other issues with EAP-PWD were found earlier, and patched in Hostap. The FreeRADIUS team was not notified of these attacks until recently. We have now patched FreeRADIUS to address these issues.

Additional issues were found by Mathy Vanhoef as part of a deep investigation into EAP-PWD. He also supplied patches to address the issues. His report is included below. This issue is recorded in VU#871675

We have released version 3.0.19 to address these issues.

Report from Mathy VanHoef

This report summarizes possible implementations-specific vulnerabilities in EAP-pwd clients or servers. Additionally, it summarizes two design flaws in EAP-pwd that all implementations are likely vulnerable to (note that you may have already received information about these design flaws previously).

Implementation-Specific Flaws

While investigating 4 different EAP-pwd implementations, we discovered that all 4 were vulnerable to invalid curve and reflection attacks. Although these are implementation-specific flaws, this indicates both vulnerabilities might be present in other implementations of EAP-pwd as well. We therefore recommend to audit EAP-pwd implementations for these two vulnerabilities.

Invalid Curve Attack

The first implementation-specific vulnerability is an invalid curve attack, and would allow an attacker to authenticate as any user (without knowing the password). The problem is that on the reception of an EAP-PWD Commit frame, a vulnerable EAP-pwd implementation does not verify whether the received elliptic curve point is valid. To fix this vulnerability, it must be checked that the received point is on the elliptic curve, and that it is not the point at infinity (e.g. using the function EC_POINT_is_on_curve and EC_POINT_is_at_infinity). Additionally, EAP-pwd implementations must check that the received scalar s is within the range 1 < s < r, where r is the order of the elliptic curve being used. If the scalar is not within this range, or the curve point is not valid, the handshake should be aborted.

An adversary can exploit the above vulnerability by sending a scalar equal to zero (or equal to the order of the elliptic curve), and by sending a specially crafted (invalid) elliptic curve point. This combination causes the negotiated session key to have a very small range of possible values. The adversary can then test each possible key until the correct session key is found. We successfully confirmed this attack against both vulnerable client-side and server-side implementations.

Reflection Attack

The second implementation-specific vulnerability might allow “fake” authentications. More precisely, an attacker can reflect the received scalar and element (i.e. elliptic curve point) that was sent by the server, in its own commit message, and subsequently reflect the confirm value as well. This causes the adversary to successfully authenticate as the victim. Fortunately, the adversary will not learn the negotiated session key, meaning the adversary cannot actually perform any actions as the victim.

This vulnerability can be patched by comparing the received scalar and curve point to the one generated by the server (i.e. by comparing it to the element and scalar that was sent to the client). If either of them are the same, the handshake should be aborted.

We successfully tested this attack against vulnerable client-side implementations of EAP-pwd.

Design Flaws

We also discovered design flaws in EAP-pwd which likely affect all implementations. Note that you may have already been informed about this in a separate announcement. In any case, we discovered the following two issues:

Timing Attacks

The password generation algorithm (the “hunting and pecking” algorithm) uses a variable number of iterations to find the password element. The precise number of iterations depends on the password being used, and on the token generated by the server. This means sensitive information is leaked if the adversary can measure how many iterations it took to derive the password element. Although making these measurements is far from trivial, obtaining this information allows the adversary to carry out a password partitioning attack (this is practically the same as an offline dictionary attack).

A backwards-compatible countermeasure is to always perform 40 iterations in the password generation algorithm. How to do this is explain in more detail in section 4.4.1 of RFC 8492, which describes a very close variant of the EAP-pwd handshake: https://tools.ietf.org/html/rfc8492#section-4.4.1 Additionally, determining whether there’s a quadratic residue should be done in a blinded manner. How this can be done is also explained in section 4.4.1 of RFC 8492.

Cache-Based Attacks

On top of the above timing attack countermeasures, implementations must also incorporate defenses against cache-based attacks. This is because the password generation algorithm (the “hunting and pecking” algorithm) contains conditional branches based on secret values. If an adversary can determine which branch of such an if-then-else branch was taken, they can learn whether the password element was found in a specific iteration of this algorithm. In practice we found that, if an adversary can run unprivileged code on the victim machine, we were able to use cache-based attacks to determine which branch was taken in an iteration of the password generation algorithm. More concretely, an adversary can determine whether the password element was found in a specific iteration or not. This information can be abused to perform a password partitioning attack (this is similar to an offline dictionary attack).

Note that this cache-based attack is only possible if an adversary can run unprivileged code on the victim’s machine (e.g. from an android application that doesn’t have special privileges, or from a co-located virtual machine).

A backward-compatible countermeasure is to replace conditional branches that depend on secret values with constant-time select utilities. See the file constant_time.md for examples on how to do this in C. Implementations must also use a constant time Legendre symbol computation.

2017.07.17Multiple issues found by Guido Vranken

We requested that Guido Vranken do fuzz testing against the server. He found issues in all versions of the server. These issues are documented on the fuzzer page.

2017.05.26Erroneous Session Resumption

We discovered that the server could be convinced to permit TLS session resumption before the authentication finished. A partial fix was put into 3.0.13. Pavel Kankovsky verified that the fix was insufficient, and provided a tool to test the issue. A better fix was put into the server, and was released in version 3.0.14.

The original EAP-TLS code would refuse to resume sessions unless there were policy attributes in the session cache. This check was put in place to work around this issue with the OpenSSL API. At some point, the code was changed to cache policy attributes by default, which opened up the vulnerability. Given the long history of the server, it is not clear when that change was made.

FIX: The short-term fix is to disable session resumption in the cache subsection of the eap module.

We believe that this issue affects version 2.1.1 through 2.1.7 inclusive. Other versions seem to be unaffected. We remind users that versions 1.0.x, 1.1.x, 2.0.x, 2.1.x, and 2.2.x are old and unsupported. Patches for those versions will not be released, as the issue can be corrected with a minor configuration change. We also note that prior to version 3, the session cache was disabled by default, and required administrator intervention to enable it.

The v4.0.x branch is not vulnerable to this issue. The underlying code has been refactored to hide the TLS session data until the final EAP Success is sent, in the Access-Accept. This change means that the issue is impossible to reoccur in the future.

At this time, we have not had reports of the issue being exploited in the wild.

2017.05.16FreeRADIUS server scanned by PVS-Studio

The people at PVS-Studio were kind enough to give us a temporary license so that we could scan FreeRADIUS. We scanned the v3.0.x branch of the server, as of commit a7df94.

You can read our write-up here.

2015.09.16Tunnel-Password Vulnerabilities

Denis Andzakovic found issues with the decryption of very long Tunnel-Passwords. The decryption routines could walk off of the end of a buffer, and write to adjacent addresses. The data being written is not under control of an attacker. The end result is usually a crash of the server.

The initial report was for version 3.0. We determined that the v3.1.x branch in git is also vulnerable. Version 2 has similar code for Tunnel-Password, which we were not able to exploit. However, for safety, all currently supported versions of the server were fixed.

The packet decoder in FreeRADIUS ensures that the only time this issue is exploitable is when a proxy server receives a long Tunnel-Password attribute in the reply from a home server. The attack cannot be performed by a RADIUS client, or an end user. As such, the exploitability of the attack is limited to systems within the trusted RADIUS environment.

We are releasing version 2.2.9 and version 3.0.10 to correct the issue.

2015.06.22Revoked intermediate certificates are not properly validated

oCert-CVE 2015-4680

All versions which implement EAP-TLS, prior to 2.2.8 and 3.0.9 do not check intermediate CAs for revocation. We have put patches into the version 2 and version 3 branches to fix these issues.

We expect that this issue has minimal effect on the majority of RADIUS systems. If you are using a self-signed CA for 802.1X, this issue does not seriously affect you, as only you can issue intermediate certificates. If you are using certificates from a public CA, then your configuration already permits third parties to issue certificates which will be accepted by your RADIUS server.

i.e. The act of using a public CA cert in RADIUS can open your systems to security issues which are larger, and much worse than this one. The fix for this particular issue does not change the underlying security problem behind using a public CA.

Our analysis of the issue led us to disagree with the analysis done by oCert, and the (alleged) original vendor who made the report. We a requested a response to our analysis, and oCert refused. We requested that the public notice contain an accurate description of the issue and it’s impact. oCert again refused. After repeated messages, the response from Andrea Barisani of oCert was:

The reporter disagrees with your assessment yet cannot share details
about their setup, oCERT has no wishes to do technical support on
their setup as we just care about the reported bug.

Which is missing the point. We never asked to do “technical support on their setup”. We asked for an accurate description of the issue and it’s impact. oCert refused, whichs means that they do not, in fact, “care about the reported bug”.

We wanted to work together to come up with an accurate description of the issue, including it’s impact. It was clear that oCert was had no such goal. They saw their work as simply taking the original report, and forwarding it to a wider audience (including us).

We can only conclude that our analysis is correct, and that the original report, and the summary published by oCert is largely wrong. We can also recommend that people avoid oCert, as they are unwilling to work with authors to publish accurate reports.

2015.04.04EAP-PWD Vulnerabilities

The EAP-PWD module performed insufficient validation on packets received from an EAP peer. This module is not enabled in the default configuration. Administrators must manually enable it for their server to be vulnerable. Only versions 3.0 up to 3.0.8 are affected.

These issues were found by Jouni Malinen as part of investigating 2015-4 for HostAP.

• The EAP-PWD packet length is not checked before the first byte is dereferenced. A zero-length EAP-PWD packet will cause the module to dereference a NULL pointer, and will cause the server to crash.
• The commit message payload length is not validated before the packet is decoded. This can result in a read overflow in the server.
• The confirm message payload length is not validated before the packet is decoded. This can result in a read overflow in the server.
• A strcpy() was used to pack a C string into an EAP-PWD packet. This would result in an over-run of the destination buffer by one byte.

2014.09.24SSLv3 (POODLE)

POODLE attack.

FreeRADIUS is not vulnerable to this issue. All version to at least 1.0.0 (and possibly earlier) require TLSv1.

2014.09.24Bash (Shellshock)

Shellshock bug.

Systems running FreeRADIUS may be vulnerable to this bug. The default configuration does not execute any external programs or shell scripts. However, administrators who have configured the server to execute shell scripts must upgrade their version of bash to a version which is not vulnerable.

2014.02.17Stack overflow in the PAP module

The CVE notification is CVE-2014-2015

The PAP module takes a “known good” password (e.g. Crypt-Password), and compares it to the password entered by the user (e.g. User-Password). In cases where the “known good” password was very long, insufficient input validation was performed. An administrator who controlled the password store could enter long passwords, and cause the server to crash.

2012.11.10Unix module allows expired passwords

The CVE notification is CVE-2011-4966.

It was found that the “unix” module ignored the password expiration setting in “/etc/shadow”. The default configuration does not use the “unix” module, so there is no issue for most deployments. However, if the server was configured to use this module for authentication, users with an expired password could successfully authenticate, even though their access should have been denied. We recommend managing users in a database, instead of leveraging /etc/passwd. The fact that a user has login access to a machine does not necessarily mean that they can use RADIUS for other kinds of network access.

2012.09.10Overflow in EAP-TLS

The CVE notification is CVE-2012-3547. The issue was found by Timo Warns, and communicated to security@freeradius.org. A sample exploit for the issue was included in the notification.

We recommend all administrators using EAP and 2.1.10, 2.1.11, 2.1.12, or the git “master’ branch upgrade immediately.

The vulnerability was created in commit a368a6f4f4aaf on August 18, 2010. Vulnerable versions include 2.1.10, 2.1.11, and 2.1.12. Also anyone running the git “master” branch after August 18, 2010 is vulnerable.

All sites using TLS-based EAP methods and the above versions are vulnerable. The only configuration change which can avoid the issue is to disable EAP-TLS, EAP-TTLS, and PEAP.

An external attacker can use this vulnerability to over-write the stack frame of the RADIUS server, and cause it to crash. In addition, more sophisticated attacks may gain additional privileges on the system running the RADIUS server.

This attack does not require local network access to the RADIUS server. It can be done by an attacker through a WiFi Access Point, so long as the Access Point is configured to use 802.1X authentication with the RADIUS server.

We scanned the rlm_eap_tls.c file with the LLVM checker-267, taken from http://clang-analyzer.llvm.org/. It did not find this issue. However, a Coverity scan did discover it.

2011.09.22Manually enabling OCSP has no effect

This issue is applicable only to version 2.1.11.

The CVE notification is CVE-2011-2701. The discoverer notified us and sent a patch.

The OCSP functionality in 2.1.11 could be enabled manually, but it would never mark certificates as revoked. As such, it did not behave as expected.

Since this issue requires manually enabling OCSP, it’s severity is low. The recommended solution is to upgrade to version 2.1.12.

2010.10.08FreeRADIUS may crash if database goes down

If FreeRADIUS depends on a database, and the database goes down for extended periods, the server may crash. This issue applies to versions 2.0.0 through 2.1.9. This issue is not externally exploitable.

The CVE notification is CVE-2010-3697.

As with many such notifications, the issuer did not communicate with us before releasing the alleged vulnerability. We also disagree with their description of the problem.

The short description of this problem is that any administrator who can (a) take the database down, or (b) disrupt communication between FreeRADIUS and the database can prevent FreeRADIUS from operating correctly. This result should not be a surprise.

In normal operation, when the server stops responding to packets (i.e. because the database is down), the NAS will stop sending it packets, and will fail over to another server. In addition, our tests indicate that this issue occurs only when the database is down for extended periods of time, and the server receives many millions of packets during that time. i.e. the problem will not occur in most deployments.

There is no possibility for privilege escalation, or access to the system running FreeRADIUS. The issue is marked “network exploitable” in the CVE database because it requires the network to be down for the attack to work.

Our recommendation is to upgrade to the latest version of the server. We also recommend that mission-critical systems be monitored. If they go offline for extended periods, they should be restarted.

2010.10.08Code modifications to the server can cause it to crash

This issue is applicable only to version 2.1.9.

The CVE notification is CVE-2010-3696.

The issuer did not communicate with us before releasing the alleged vulnerability, and we disagree with their description of the problem.

The DHCP functionality in 2.1.9 is not enabled by default. Enabling it requires code modifications, a complete re-build and re-install of the server, and a manual enabling of DHCP in the configuration. Further, the DHCP functionality is marked “experimental” in this release. As such, it should be used only on trusted networks.

This issue is exploitable whenever FreeRADIUS has had DHCP functionality enabled, and where the administrator has manually configured the server to accept DHCP packets. Any DHCP packet with a “Relay Agent” sub-option can cause FreeRADIUS to enter an infinite loop.

Our recommendation is to run experimental features only in trusted networks.

2010.02.03Apple Mac OS X server misconfiguration

CVE-2010-0524 - This issue only affects Mac OS X Server systems.

Apple had apparently configured FreeRADIUS to accept all “well known” Certificate Authorities as valid for EAP-TLS. This configuration permitted almost anyone to create a client certificate for use with EAP-TLS, which would then be accepted by Mac OS X Server systems.

We recommend that the list of Certificate Authorities configured in FreeRADIUS be audited, and kept as small as possible.

2009.09.09Server crash with Tunnel-Password attribute

Anyone who can send packets to the server can crash it by sending a Tunnel-Password attribute in an Access-Request packet. This vulnerability is not otherwise exploitable. We have released 1.1.8 to correct this vulnerability.

This issue is similar to the previous Tunnel-Password issue noted below. The vulnerable versions are 1.1.3 through 1.1.7. Version 2.x is not affected.

2007.04.10Memory leak in EAP-TTLS can cause server crash

This issue affects version 1.1.5 and earlier.

A malicous 802.1x supplicant could send malformed Diameter format attributes inside of an EAP-TTLS tunnel. The server would reject the authentication request, but would leak one VALUE_PAIR data structure, of approximately 300 bytes. If an attacker performed the attack many times (e.g. thousands or more over a period of minutes to hours), the server could leak megabytes of memory, potentially leading to an “out of memory” condition, and early process exit.

We recommend that administrators using EAP-TTLS upgrade immediately.

This bug was found as part of the Coverity Scan project.

2007.01.02Stack overflow in rlm_smb means admins can write to server config

SMB_Handle_Type SMB_Connect_Server.

While the summary is superficially correct, and there is a stack overflow in rlm_smb, the issue is less problematic than it sounds.

CVE-2007-0080 has been updated with our statement.

SecurityTracker Alert ID: 1017463 has been updated with our statement.

freeradius-smbconnectserver-bo (31248) has been updated to no longer claim the issue is remotely exploitable. They do not, however, include our vendor statement, though they do reference it. They also list the issue as “High Risk”, and “Gain Privileges”, which is NOT TRUE, for the reasons outlined below.

In summary, the issue is not remotely exploitable. It is exploitable by local administrators who have write access to the server configuration files. If an attacker can write to the server configuration files, they can configure the server to run arbitrary programs. Exploiting the server via a stack overflow would be unnecessary.

The solution to this “vulnerability”, of course, is to ensure that only the correct people are given write access to the server configuration files.

2006.03.20Insufficient input validation in MS-CHAP

A validation issue exists with the EAP-MSCHAPv2 module in all versions from 1.0.0 (where the module first appeared) to 1.1.0. Insufficient input validation was being done in the EAP-MSCHAPv2 state machine. A malicious attacker could manipulate their EAP-MSCHAPv2 client state machine to potentially convince the server to bypass authentication checks. This bypassing could also result in the server crashing. We recommend that administrators upgrade immediately.

2005.09.09Multiple SQL vulnerabilities

Multiple issues exist with version 1.0.4, and all prior versions of the server. Externally exploitable vulnerabilities exist only for sites that use the rlm_sqlcounter module. Those sites may be vulnerable to SQL injection attacks, similar to the issues noted below. All sites that have not deployed the rlm_sqlcounter module are not vulnerable to external exploits. However, we still recommend that all sites upgrade to version 1.0.5.

The issues are:

• SQL Injection attack in the rlm_sqlcounter module.
• Buffer overflow in the rlm_sqlcounter module, that may cause a server crash.
• Buffer overflow while expanding %t, that may cause a server crash.

These issues were found by Primoz Bratanic. As the rlm_sqlcounter module is marked “experimental” in the server source, it is not enabled or configured in most sites. As a result, we believe that the number of vulnerable sites is low.

Additional issues, not externally exploitable, were found by Suse. A full response to their report is available here. A related post to the vendor-sec mailing list is found here.

2005.05.01Two SQL vulnerabilities

Two vulnerabilities in the SQL module exist in all versions prior to 1.0.3. Sites not using the SQL module are not affected by this issue. However, we still recommend that all sites upgrade to version 1.0.3.

The issues are:

• Buffer overflow - A long string could overflow an internal buffer in the SQL module, and write two bytes of text [0-9a-f] past the end of the buffer. The server may exit when this happens, resulting in a DoS attack. Depending on the local configuration of the server, this may occur before a user is authenticated. This vulnerability is externally exploitable, but can not result in the execution of arbitrary code.
• SQL injection attacks - The SQL module suffers from SQL injection attacks in the group_membership_query, simul_count_query, and simul_verify_query configuration entries. The first query is exploitable if your site is configured to use the SQL-Group attribute in any module in the authorize section of radiusd.conf. The last two queries are exploitable only if your site has user names that contain a single quote character (').

2004.09.14Multiple external DoS attacks

Multiple external DoS attacks exist in the server. These are related to the attacks below, in 0.9.2, but were not caught then. The vulnerabilities are fixed in 1.0.1, and in all later versions of the server. The vulnerabilities are not exploitable, but can be used to remotely crash the server.

2003.11.20Externally exploitable root compromise in rlm_smb

There is an externally exploitable root compromise in rlm_smb, through a stack overflow when a password greater than 128 bytes referenced by the module. The module is not built or installed by default, so we have not released a 0.9.4. This vulnerability is fixed in the CVS snapshots, and will be included in any later release of the server.

2003.10.15Crash upon receipt of Tunnel-Password attribute

Anyone who can send packets to the server can crash it by sending a Tunnel-Password attribute in an Access-Request packet. This vulnerability is not otherwise exploitable. We have released 0.9.3 to correct this vulnerability.

2002.07.26Kerberos module may grant incorrect access

The Kerberos module may grant access to a user whose Kerberos ticket cannot be verified against the server principal. We have released 0.7.1 to correct this vulnerability.

2001.12.17Multiple RADIUS vulnerabilities

CA-2002-06. Multiple vulnerabilities in multiple RADIUS implementations. We have released 0.4 to correct these vulnerabilities.

2014.04.08OpenSSL Heartbleed

Heartbleed bug.

OpenSSL has a major security issue, seen in to CVE-2014-0160. The issue mainly affects servers such as SMTPS or HTTPS, which allow random IP addresses to connect to them via TLS. Those sites must assume that all information available to the system using TLS has been compromised.

Based on further information from Jouni Malinen, it appears that both Version 2 and Version 3 of FreeRADIUS are vulnerable to the attack. It is likely that earlier versions of the server are vulnerable, too.

The problem appears to be that OpenSSL has already allowed invalid reads by the time that FreeRADIUS detects the invalid heartbeat, and closes the connection. The benefit of the way FreeRADIUS uses OpenSSL is that the attack appears to be limited to reading ~1K of data from the stack, when the server receives the malicious heartbeat. This limitation mitigates the attack, but does not remove the possibility of exposing private information.

We recommend that all administrators upgrade OpenSSL immediately.

Administrators can detect “heartbleed” attacks by looking in their logs for a message containing the text Invalid ACK received: 24. If such a message is seen, it means that the attack has been attempted. You should upgrade your version of OpenSSL immediately.

We suggest that all administrators upgrade all of their systems to a version of OpenSSL which is not vulnerable to this attack. Sites which allow random IPs to connect to a TLS server (e.g. SMTPS or HTTPS) should assume that all information available to those servers has been stolen from those systems. This information includes user credentials, keys for private certificates, cookies sent over HTTPS, etc.

We have updated FreeRADIUS (all versions) so that it refuses to start when it detects the vulnerable versions of OpenSSL.

v3.0.x - Administrators can over-ride this check by setting allow_vulnerable_openssl = CVE-2014-0160 in the security subsection of radiusd.conf.

v2.2.x - Administrators can over-ride this check by setting allow_vulnerable_openssl = yes in the security subsection of radiusd.conf.

2012.04.19Versions of OpenSSL are vulnerable to malformed certificates

The CVE notification is CVE-2012-2110.

We recommend all administrators using certificates with FreeRADIUS upgrade their OpenSSL to a secure version. For details, see the OpenSSL notification

We emphasize that this is not a bug in FreeRADIUS. FreeRADIUS uses OpenSSL for many of it’s cryptographic operations, and as such, is at the mercy of any problems in OpenSSL.

2008.05.13SSL keys may be guessable

A bug added to OpenSSL on Debian and Ubuntu systems means that SSL keys on those systems may be guessable.

We recommend that administrators using OpenSSL on Debian or Ubuntu upgrade immediately. We also recommend re-generating any SSL certificates used in RADIUS systems, if those certificates were created on a Debian or Ubuntu system since 2006.

We emphasize that this is not a bug in FreeRADIUS. FreeRADIUS uses OpenSSL for many of it’s cryptographic operations, and as such, is at the mercy of any problems in OpenSSL.