Dear Maintainer,

freeradius with openssl 3.0.13-1~deb12u1 cannot successfully communicate
with eapol_test from bullseye (2:2.10-8~bpo11+2, openssl 1.1.1w-0+deb11u1).
eapol_test is used by our monitoring system to verify the functionality
of our freeradius services.

Server log shows the received Access-Request is handled and Access-Challenge
is sent. However eapol_test simply ignores it and re-sends Access-Request
packets again and again:

Sending RADIUS message to authentication server
RADIUS message: code=1 (Access-Request) identifier=0 length=146
   Attribute 1 (User-Name) length=21
      Value: 'anonymous@wigner.hu'
   Attribute 4 (NAS-IP-Address) length=6
      Value: 127.0.0.1
   Attribute 31 (Calling-Station-Id) length=19
      Value: '02-00-00-00-00-01'
      Value: '02-00-00-00-00-01'
   Attribute 12 (Framed-MTU) length=6
      Value: 1400
   Attribute 61 (NAS-Port-Type) length=6
      Value: 19
   Attribute 77 (Connect-Info) length=24
      Value: 'CONNECT 11Mbps 802.11b'
   Attribute 79 (EAP-Message) length=26
      Value: 0200001801616e6f6e796d6f7573407769676e65722e6875
   Attribute 80 (Message-Authenticator) length=18
      Value: 7de9f48818e89058d448e4016e4d183c
ext RADIUS client retransmit in 3 seconds
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: startWhen --> 0
STA 02:00:00:00:00:01: Resending RADIUS message (id=0)

Next RADIUS client retransmit in 6 seconds
...

Tcpdump shows the Access-Challenge packet is indeed delivered to the client.
If the same configuration (both on server and eapol_test sides) is tested
with eapoltest from bookworm (2:2.10-12+deb12u1, openssl 3.0.13-1~deb12u1),
it is successful.

I was not able to come up with a TLS configuration (tls_min_version,
tls_max_version, cipher_list, ecdh_curve) in freeradius which could fix it.

The issue is critical becasue possibly all clients with openssl 1.1.1w-0+deb11u1
might be affected.

Thanks,
Jozsef

Control: reassign -1 eapoltest
Control: found -1 2:2.10-8

This sounds like a bug in eapoltest, not in Freeradius. Reassigning
accordingly.

Note that the version in bullseye-backports is older than the one in
bookworm it should base on. The version in bullseye-backports is missing
these fixes from bookworm (stable). Some of those sound related.

I'm not sure whether bullseye-backports is still updateable, if yes it
might be a good idea to backport the current stable-security version.

wpa (2:2.10-12+deb12u1) bookworm; urgency=high

   * Non-maintainer upload on behalf of the Security Team.
   * Fix CVE-2023-52160 (Closes: #1064061):
     The implementation of PEAP in wpa_supplicant allows
     authentication bypass. For a successful attack,
     wpa_supplicant must be configured to not verify
     the network's TLS certificate during Phase 1
     authentication, and an eap_peap_decrypt vulnerability
     can then be abused to skip Phase 2 authentication.
     The attack vector is sending an EAP-TLV Success packet
     instead of starting Phase 2. This allows an adversary
     to impersonate Enterprise Wi-Fi networks.


We can't rule that out, but we haven't heard of any reports.

Bernhard

I have just downloaded the source code of eapol_test from bookworm
(wpa-2.10), recompiled on a bullseye system and run the same test.

It did not help, eapol_test cannot successfully communicate with the
freeradius server. So the results so far:

eapol_test from bullseye with libssl.so.1.1	failure
eapol_test from bookworm with libssl.so.1.1	failure
eapol_test from bookworm with libssl.so.3	ok

Best regards,
Jozsef