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.