STE WILLIAMS

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.

Buffer overflow

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 AAAAAATHIS­ISLONGER­THAN­THIRTYTWO­CHARACTERS­SOWATCHOUT), 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.

Follow @duckblog

Image of Wi-Fi icon bursting forth from tablet courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/YkTZ2877nGA/