[Pkg-freeradius-maintainers] Bug#926958: Proposed security upload for FreeRADIUS

[Bernhard Schmidt]

Am 24.04.19 um 21:23 schrieb Salvatore Bonaccorso:

Hi Salvatore,

>> I've gained access to the FreeRADIUS salsa repo and have pushed a new
>> debian/stretch branch containing last years security upload and the
>> cherry-picked fixes for #926958
>>
>> It applies and builds cleanly, I'm currently waiting for a colleague who
>> runs our Radius proxies to test it.
> 
> Looking closer now again at the issue, if I understand correctly, the
> module would not be enabled by default and to exploit the issue one
> would actually as well need to have access to the authentication
> server.

It's not enabled by default, that's correct. I think universities are
pushing for it because it is a secure-with-default configuration to
authenticate eduroam users, compared to EAP-TTLS or MSCHAPv2 where
security relies on a proper TLS verification no user is configuring
manually.

I have no idea whatsoever about the inner workings of the EAP-PWD
algorithm and I don't even try to understand EC cryptography, but as far
as I understand both FreeRADIUS CVEs are not about timing attacks, but
missing validation of user-supplied parameters.

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

I think the timing-based attack was the one in src:wpa (Dragonblood)
CVE-2019-9494, CVE-2019-9495

The two redhat bug tracker entries you linked say

CVE-2019-11234 freeradius: eap-pwd: fake authentication using reflection

A vulnerability was found in FreeRadius. An attacker can reflect the
received scalar and element from the server in it's 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 posses the negotiated session key, meaning the
adversary cannot actually perform any actions as this user.


CVE-2019-11235 freeradius: eap-pwd: authentication bypass via an invalid
curve attack

A vulnerability was found in FreeRadius. An invalid curve attack allows
an attacker to authenticate as any user (without knowing the password).
The problem is that on the reception of an EAP-PWD Commit frame,
FreeRADIUS doesn't verify whether the received elliptic curve point is
valid.

> Unless I miss something in the picture, I would say this could be
> fixed via the next point release for stretch, and does not warrant a
> DSA on its own.
> 
> Do I miss something?

I'm fine with that as well, I'm not keen on doing a security nmu I don't
really understand. Letting it cool down in -proposed might be a good
idea. Let me know how to proceed.

Best Regards,
Bernhard