OpenSSL TLS heartbeat vulnerability and wpa_supplicant

[Jouni Malinen]

Unfortunately, my initial tests used parameters that were not able to
get the EAP TLS implementation in wpa_supplicant to send the incorrect
heartbeat response from OpenSSL to the test EAP server. It has now been
shown that it is indeed possible to do this and as such, the OpenSSL
vulnerability (*) could (and obviously still can if the device is still
using the vulnerable version!) have been attacked through EAP
authentication.

With the updated design on the test tool, I have now been able to
extract the client private key from wpa_supplicant linked against the
vulnerable OpenSSL version. Consequently, I have to recommend any TLS
private key that may have been enabled in wpa_supplicant with the
vulnerable OpenSSL version to be replaced with a new one since there is
possibility of a rogue server having been able to extract it from the
client.

While I have not yet seen other private information exposed in a
practical attack, there is no reason to believe that other configuration
data (e.g., network PSK/passphrase/password) would have been safe from
this attack either. Fetching these is somewhat more complex, but it
looks likely that it could be done in some operation sequences that make
the heap allocations line up suitably before the attack. As such, it
would sound justifiable to make sure that any PSK/passphrase/password
that has been included in wpa_supplicant configuration that also enables
TLS-based EAP method is replaced if the vulnerable OpenSSL versions have
been used with such configuration.

If someone is still using the vulnerable OpenSSL version, I would
strongly urge the device to be updated. There are now publicly available
tools that make it trivial to exploit this issue through various
protocols, including through a rogue AP to attack any WPA2-Enterprise
client. While it is obviously somewhat more difficult to convince client
devices to do something that allows the vulnerability to be exploited
compared to how easy it is to access Internet connected servers, it
needs to be understood that this is by no means impossible. A rogue AP
in a public location can be used relatively easily to get client devices
to try to connect if they have Wi-Fi enabled and a matching SSID in a
network profile (and in most cases, due to active scanning, it is
trivial to figure out such a matching SSID). As such, I consider this to
be a very viable attack against Wi-Fi client devices that have any
EAP-TLS/TTLS/PEAP/FAST profile enabled.


(*)
http://www.openssl.org/news/secadv_20140407.txt
CVE-2014-0160

-- 
Jouni Malinen                                            PGP id EFC895FA