Radiator is not affected by log4j vulnerability

On the 10th of December 2021 a vulnerability (CVE-2021-44228) in a popular Java-based logging utility log4j was published. Since then we have received some customer queries about Radiator’s vulnerability.

Radiator does not utilise Java or log4j as a component of our software and is therefore not vulnerable to the log4j vulnerability.

While following closely the situation, research and responses around the vulnerability, we have identified that RADIUS protocol and infrastructure can be used to deliver the exploit to more vulnerable services such as Java-based backend services, AAA information sources and centralised logging systems. We have documented this delivery method principle into a separate blog post found here:

https://blog.radiatorsoftware.com/2021/12/radius-servers-and-log4j-vulnerability.html

We will continue monitoring the issue closely and announce if issues affecting Radiator or Radiator services are found.

RADIUS servers and log4j vulnerability

On the 10th of December 2021 a vulnerability (CVE-2021-44228) in a popular Java-based logging utility log4j was published. While Radiator and some other RADIUS servers are not themselves vulnerable, log4j may be used in Java based user interfaces, log processors and many other supporting services and software. The systems and networks using RADIUS authentication can then be used to deliver the exploit to some other vulnerable services even if the exploit does not affect the RADIUS server systems directly.

Figure 1: RADIUS infrastructure as a delivery method for log4j exploits

The attacker can always try to exploit accessible network devices directly. Many network devices nowadays use Java based user interfaces and logging systems, which include log4j as a component and are therefore vulnerable to a direct attack. The attack can however reach deeper into backend services via RADIUS authentication without the need for the attacker to reach the actual backend services directly.

If the attacker is able to get the network device to add a suitable exploit payload to the RADIUS request, that payload can then be delivered through the RADIUS server to backend services and even outside one organisation. The payload does not affect the RADIUS servers themselves (unless they use Java and log4j) but RADIUS and RADIUS federations may be used as a delivery mechanism for exploits to reach more interesting targets.

Mitigating the risk by filtering and sanitising RADIUS attributes in RADIUS servers is likely to break more than it protects. It is more productive to focus on updating or possibly replacing log4j using systems than trying to prevent the delivery of the exploit.