WPA vulnerability KRACK

[nuclearcat]

Hi, as esp-open-rtos uses libwpa.a and it seems it is based on wpa_supplicant code - there is serious bug, that was patched recently. ESP issued updates for SDK, and also wpa_supplicant too, but as i see object is binary - i can't make any patch to it, it seems only maintainers of esp-open-rtos know what is better to do with this issue.

[flannelhead]

Yeah - that's too bad since this project is using the last version of the SDK using the standard MIT license, not the later ones that have the incompatible Espressif MIT license.

I wonder what we can do to handle this.

[nuclearcat]

Maybe worth to try to ask Espressif if they can do exception and release patched version of last MIT licensed library? This will be very nice and friendly step from their side.

[projectgus]

(This is not an official Espressif opinion, just my personal thoughts.)

I think the library version used in esp-open-rtos is so old (2.5 years now) that releasing a patched version will be very difficult and unlikely. :(

There was some discussion in the recent past about moving the binary libraries to a newer Espressif RTOS SDK version (I can't find the discussion right now). The esp-open-rtos project has been successful enough that these are almost all directly WiFi-related at this point, I think. As well as the KRACK fix there are new power management capabilities, other PHY & MAC layer fixes, etc. The rest of the project could stay with its current licensing.

Maybe this is something the community could consider again, although it would still be a lot of porting work. Of course I don't have any say in this any more, it'd be up to the current active maintainers.

[ourairquality]

From working on the lwip v2 code and working around the edges of the wpa library, it looked like relatively standard upstream code, not much specific to the hardware, perhaps stripped down a lot. We probably have enough to install the keys and send the packets etc. Clearly an open port of the upstream hostap code is needed and where we want to be moving, even if moving to more recent binaries for the PHY and MAC layers. It would be a surprise if there were any power management improvements in the wpa library. This it probably one of the next projects to do - that and finishing libmain.

[kanflo]

Glad to see you drop by @projectgus. For those who have not git-blamed the code base here, Angus is the original author of the EOR project. I would not mind moving to newer libraries for several reasons, KRACK and power management being two.

[jeffsf]

As noted in #473

Espressif Releases Patches for WiFi Vulnerabilities (CERT VU#228519)

ESP8266 RTOS (ESP8266) master branch, since commit 2fab9e23d779cdd6e5900b8ba2b588e30d9b08c4

Source: http://espressif.com/en/media_overview/news/espressif-releases-patches-wifi-vulnerabilities-cert-vu228519

[sheinz]

There's no easy solution out of this situation. We can't easily go back to the current Espressif binary SDK as it would mean throw away all the reverse engineering work. Current Espressif RTOS SDK moved too far and I don't think we can selectively update some libraries and leave the rewritten ones as it is. (If we can, I'm not against it)

The idea to have open upstream wpa_supplican code is very cool! And it would mean that everybody can see how vulnerability patch is implemented. Not just blindly trusting that the vendor has fixed the bug, seeing just a commit hash...

@ourairquality has done a lot for opening binary blobs. Do you think it is feasible to open enough to use upstream wpa_supplican code?

[ourairquality]

fwiw: I was able to build from the current hostap source code and get the station and softap modes working. It was a quick hack, not robust. Was more work than expected, mainly due to not having the libnet80211 source code.

There appear to be some significant issues with the management of gtk key indexes, there might only be an allocation for two in the lower level organisation, but potentially four. Fixing this probably needs coordination with libnet80211.

Also noted that the current hostap code has removed the WEP support, but that is probably not a big loss.

Have issues in my country distributing this type of code, it might be a dead end for me. Probably the main clue people need is to understand how the hardware keys are installed. There is the function:

ppInstallKey(uint8_t alg, uint8_t *hwaddr, uint32_t key_idx, uint32_t set_tx, void * seq, uint32_t seq_len, uint8_t * key, uint8_t key_len, uint32_t arg8)
alg - 2 tkip, 3 wep, 1,5 wep?
hwaddr - the MAC address to match.
key_idx - probably should be 0 for ptk and 0 to 3 for gtk. (only 1 and 2 might be supported for gtk, bug?)
set_tx - ignored!
seq_len, seq - this is just the initial sequence number, it is stashed in the ieee80211 software structures, used by the software to encap/decap the frames.
key, key_len - there seems to be hardware support using the key, it is the same key that the hostap code generates, length is 16 for aes ccmp, 32 for tkip.
arg8 - this seems to indicate a lower level index to use to manage the key. There might be at least 14 of these, the first two might be for broadcast addresses on each interface installed at startup, the next two for station gtks, the next two for softap gtks, the next four for the station ptks, the next four (or more) for the softap ptk. Not sure if the ordering is hardware restricted or if this is just the organisation the software chose.

So for this to really be serviceable the libnet80211 source code would be needed too as it deals much of the authentication support. It's rather disappointing to have to go to these lengths just to have a serviceable code base, it might not be practical, and personally I will need to consider if it is even worth the effort.

[vlad-ivanov-name]

Regarding reverse engineering: Retargetable Decompiler was opensourced by Avast a few days ago. It doesn't support xtensa and neither does its disassembler backend, capstone. I wonder if the amount of effort required to implement it is worth it. In my experience, RetDec is good enough to decode general control flow. I also have tried to convert some simple SDK functions related to power management to ARM code and RetDec was able to recreate bitmasks, polling and so on.