A bug has just been announced in an open source program called wpa_supplicant.
Many of us use this program on a regular basis, often without even realising it.
Android devices, for example, include it as part of the operating system distribution; support for Wi-Fi enabled devices on Linux almost always relies on it.
That’s because it’s software that deals with finding, connecting to, and authenticating against Wi-Fi access points that use WPA security.
Why use WPA?
If you’ve followed Naked Security’s advice, you’ll long ago have switched from an open access point, or from WEP security (WPA’s precursor), to WPA or WPA2.
Open access points are risky because anyone passing by can connect, and effortlessly listen in to your network traffic.
If you do online banking using HTTPS, you’ll be safe, but a lot of the other things you do online will be wide open for what’s known as sniffing – eavesdropping and recording the data going past on the network.
Sniffed data can then be mined for interesting information like email addresses, usernames, instant messages, passwords; indeed, anything that isn’t properly encrypted.
WEP is worse than risky: it encrypts all your traffic with a secret password, so it’s supposed to be secure, but it isn’t.
Because of a fault in the underlying algorithms used in WEP, you can work backwards from the encrypted data to the password, using cracking software that takes typically takes just a few minutes to run.
That means you need to use WPA, and, as mentioned above, on Androids and many Linuxes, that means wpa_supplicant, even though that’s probably not obvious.
Unfortunately, wpa_supplicant turned out to have a buffer overflow.
That’s where you send the program some data – in this case, a network name – but deliberately make it super-long.
If the program doesn’t check that the data is going to fit (perhaps on the assumption that no-one would ever bother with a network name like AAAAAATHISISLONGERTHANTHIRTYTWOCHARACTERSSOWATCHOUT), then other important data stored nearby in memory may be corrupted, and the program will probably crash.
With a mixture of analysis and deduction, crooks may be able to figure out how to orchestrate the crash in such a way that they trick your computer into running some other fragment of code of their own choosing.
Often, that gives them full access to your computer, just as if they were logged in themselves, in an outcome that’s known as RCE, or remote code execution.
That’s a possible outcome, amongst many others, from this bug:
This could result in corrupted state in heap, unexpected program behavior due to corrupted P2P peer device information, denial of service due to wpa_supplicant process crash, exposure of memory contents during GO Negotiation, and potentially arbitrary code execution.
Fortunately, the bug can only be triggered if wpa_supplicant is dealing with a special sort of connection called Wi-Fi Direct, also known as Wi-Fi P2P (peer-to-peer).
That’s a way of connecting directly between two devices that doesn’t go through a Wi-Fi access point – much like a Bluetooth hookup, only faster.
Not all wpa_supplicant versions support Wi-Fi Direct, but Android does.
So, unfortunately, it looks as though many Android devices could be at risk.
Finding and fixing the bug
Tracking how memory is allocated and used in the offending parts of the wpa_supplicant code made our eyes water, but we were able to take a shortcut: there’s a one-line source code patch available.
The patch adds a missing safety check to an “if” statement, which suppresses the bug:
Don’t worry if you don’t understand C: all you need to know is that the added code makes sure that the network name you sent to it really does fit into the 32 bytes of memory that the software has set aside for the purpose.
In fact, network names aren’t supposed to be longer than 32 characters in the first place, so this check really ought to have been in the code regardless of any buffer size issues.
What to do?
If you run your own version of Android or Linux, and are able to reconfigure or recompile it, you can do any or all of the following:
- Apply the above patch to your wpa_supplicant source code and rebuild.
- Rebuild with P2P support excluded altogether. (CONFIG_P2P=n)
- Run wpa_supplicant with P2P support turned off. (p2p_disabled=1)
If you are using a vendor’s build, keep your eyes open for an update.
If you aren’t sure whether your operating system (or application software, router or appliance) uses wpa_supplicant, ask your vendor or distro maintainer.
NB. The Sophos product range includes Wi-Fi devices, but they do not have wpa_supplicant installed.
Image of Wi-Fi icon bursting forth from tablet courtesy of Shutterstock.
7 comments on “Wi-Fi security software chokes on network names, opens potential hole for hackers”
Hi Paul – thanks for the heads up.
Just as a clarification – is my Android at risk simply because my Wi-Fi is on, or do I have to attempt to use Wi-Fi Direct myself to be at risk from attack?
It seems that the bug can in theory be triggered not only when your device tries to set up a Wi-Fi Direct connection (i.e. is expecting various reply packets that could include a treacherous network name), but also when another device is merely “asking around” to nearby devices about their support for Wi-Fi Direct.
Fortunately, however, the bug report suggests that the latter sort of attack (which would be very much more serious) is pie-in-the-sky at the moment:
“The vulnerability is easiest to exploit while the device has started an active P2P operation (e.g., has ongoing P2P_FIND or P2P_LISTEN control interface command in progress). However, it may be possible, though significantly more difficult, to trigger this even without any active P2P operation in progress.”
I am not sure how you turn off Wi-Fi Direct altogether if your Android supports it, or even if you can…we’ll keep you updated if we learn more.
Muchas gracias (-:
“Fortunately, the bug can only be triggered if wpa_supplicant is dealing with a special sort of connection called Wi-Fi Direct, also known as Wi-Fi P2P (peer-to-peer).
“That’s a way of connecting directly between two devices that doesn’t go through a Wi-Fi access point – much like a Bluetooth hookup, only faster.”
Ummm, don’t you mean an “ad hoc” connection?
No, it’s not an ad hoc connection. It’s sort of similar to an ad hoc connection, except that there’s a whole protocol around how the two devices dance around each other to get connected in the first place. (My understanding is that one end of the connection essentially ends up as a special sort of WPA access point, with some sort of WPS-like stage in the hook-up whereby the ends agree on cryptographic material and connect up.)
Part of the danger here is that many carriers don’t release timely patches for their Android devices. This means that you may be forced to apply the security patch yourself. It’s probably worth asking your carrier about this issue to ensure they do push any related upstream patches to your device.
Timely patches? Many of them do not release updates at all. There’s no incentive to update the OS on a device you’ve already sold when you can let it get out of date quicker and force the customer to buy a new device.