Currently browsing: General

Overview
A use-after-free vulnerability in lighttpd in versions 1.4.50 and earlier permits a remote, unauthenticated attacker to trigger lighttpd to read from invalid pointers in memory. The attacker can use crafted HTTP Requests to crash the web server and/or leak memory in order to access sensitive data. This vulnerability was fixed in 2018 by the lighttpd project. However, a number of implementations of lighttpd remain vulnerable due to a failure to apply the security updates provided by lighttpd.
Description
lighttpd is a lightweight web server software that is meant for low resource environments with limited CPU and memory. This open-source software is available in binary form and source code that is included in various IoT and firmware environments. In November of 2018, VDOO researchers disclosed a vulnerability related to the HTTP header parsing code in lighttpd versions 1.4.50 and earlier. This security issue was fixed by lighttpd as part of their 1.4.51 release in August 2018. At the time of disclosure, VDOO researchers identified the primary impact to be Denial of Service (DoS) using the released memory pointer.
However, a CVE ID was not obtained as part of the fix outlined above, leaving the vulnerability without a public identifier. In April of 2024, Binarly discovered that the lighttpd vulnerability was still present in a number of products, presenting a supply-chain risk. The lack of CVE ID rendered the security fix invisible to projects that utilize earlier versions of lighttpd. Many organizations depend on a public CVE ID record to initiate security fixes and apply software updates. Binarly also documented many implementations of lighttpd (versions 1.4.50 and earlier) that allowed for a different set of attacks that can leak memory and access sensitive data. The supply-chain impact of this vulnerable software includes multiple products as highlighted in the blog by runZero. The lighttpd project has now obtained CVE-2018-25103 to identify this vulnerability and to alert supply-chain partners to implement the required fix.
Impact
The impact of this vulnerability varies largely due to the various ways lighttpd can be used a web server in various product implementations. In general, a remote unauthenticated attacker can use crafted HTTP Requests to crash the web server and/or leak memory in order to access sensitive data, such as process memory addresses.
Solution
The CERT/CC recommends applying the latest vendor-provided patch to address this issue. Review the Vendor Information below or contact your vendor or supplier for specific mitigation advice. If your device’s implementation of lighttpd is deemed end-of-life or end-of-support, replace your hardware or software as appropriate to avoid exposure to this vulnerability. Operators can also limit network access to lighttpd implementations to avoid exposure of this software to the public Internet and untrusted sources.
Acknowledgements
Thanks to Binarly for highlighting this vulnerability in supply-chain implementations. Thanks to Ori Hollander, VDOO for identifying and reporting the vulnerability in 2018. Thanks also to lighttpd project and vendor AMI that cooperated in supporting this public disclosure and outreach.This document was written by Vijay Sarvepalli.

Overview
A vulnerability in the RADIUS protocol allows an attacker allows an attacker to forge an authentication response in cases where a Message-Authenticator attribute is not required or enforced. This vulnerability results from a cryptographically insecure integrity check when validating authentication responses from a RADIUS server.
Description
RADIUS is a popular lightweight authentication protocol used for networking devices specified in IETF 2058 as early as 1997 (obsoleted by RFC 2138 and then RFC 2865. There have been several other IETF standards (RADIUS/TCP, RADIUS/TLS and RADIUS/DTLS) that cover and enhance various parts of the specification for the use of RADIUS in authentication. RADIUS is widely used to authenticate both users and devices and widely supported by networking devices, from basic network switches to more complex VPN solutions. Recently, RADIUS has also been adopted in much of the cloud services that provide tiered, role-based access-control to resources. As a client-server protocol, RADIUS uses a Request-Response model to verify authentication requests and further provide any role-based access using Groups. RADIUS can also be proxied to support multi-tenant roaming access services.
A vulnerability in the verification of RADIUS Response from a RADIUS server has been disclosed by a team of researchers from UC San Diego and their partners. An attacker, with access to the network where the RADIUS protocol is being transmitted, can spoof a UDP-based RADIUS Response packet to modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response, with almost any content, completely under the attackers control. This allows the attacker to transform a Reject into an Accept without knowledge of the shared secret between the RADIUS client and server. The attack is possible due to a basic flaw in the RADIUS protocol specification that uses a MD5 hash to verify the response, along with the fact that part of the hashed text is predictable allowing for a chosen-prefix collision. The attack, demonstrated by UCSD team, takes advantage of the chosen-prefix collision of the MD5 message in a novel way. The widespread use of RADIUS and its adoption into the cloud allows for such attacks to pose a reasonable threat to the authentication verification process that relies on RADIUS.
RADIUS servers that only perform Extensible Authentication Protocol (EAP), as specified in RFC 3579, are unaffected by this attack. The EAP authentication messages require the Message-Authenticator attribute, which will prevent these attacks from succeeding. The use of TLS (or DTLS) encryption can also prevent such attacks from succeeding. However, RADIUS over TCP itself can still be susceptible to this attack, with more advanced man-in-the-middle scenarios, to successfully attack the TCP connection.
Finally as explained by Alan Dekok, developer of FreeRadius open source software –

The key to the attack is that in many cases, Access-Request packets have no authentication or integrity checks. An attacker can then perform a chosen prefix attack, which allows modifying the Access-Request in order to replace a valid response with one chosen by the attacker. Even though the response is authenticated and integrity checked, the chosen prefix vulnerability allows the attacker to modify the response packet, almost at will.

Impact
An attacker with access to the network where RADIUS Access-Request is transported can craft a response to the RADIUS server irrespective of the type of response (Access-Accept, Access-Reject, Access-Challenge, or Protocol-Error) to modify the response to any of the valid responses. This can allow an attacker to change the Reject response to an Accept or vice versa. The attack can also potentially intercept an Access-Challenge, typically used in Multi-Factor Authentication (MFA), and modify it to an Access-Accept, thus bypassing the MFA used within RADIUS. Due to the flexible, proxied nature of the RADIUS protocol, any server in the chain of proxied RADIUS servers can be targeted to succeed in the attack.
Solution
Device Manufacturers
RADIUS-compliant software and hardware manufacturers should adopt the recommendations from the Article document to mitigate the risk of the RADIUS protocol limitations identified in this attack. Manufacturers who bundle the open-source RADIUS implementations, such as FreeRadius, should update to the latest available software for both clients and servers and, at a minimum, require the use of the Message-Authenticator for RADIUS authentication.
Operators
Network operators who rely on the RADIUS-based protocol for device and/or user authentication should update their software and configuration to a secure form of the protocol for both clients and servers. This can be done by enforcing TLS or DTLS encryption to secure the communications between the RADIUS client and server. Where possible, network isolation and secure VPN tunnel communications should be enforced for the RADIUS protocol to restrict access to these network resources from untrusted sources.
Acknowledgements
Thanks to Sharon Goldberg, Miro Haller, Nadia Heninger, Mike Milano, Dan Shumow, Marc Stevens, and Adam Suhl who collaborated for this research and supported coordinated vulnerability disclosure to reach multiple vendors and stakeholders. Thanks to Alan Dekok for spearheading the IETF proposal and recommendations. This document was written by Vijay Sarvepalli and Timur Snoke.