Thanks. Used the command line to upgrade.
opkg update
opkg list-upgradable
opkg upgrade luci-mod-admin-full
reboot
Is the new wpa_disable_eapol_key_retries feature actually tested and verified to prevent the krack expoit with vulnerable clients?
1 Like
Since this is a problem that is going to be around pretty much forever (due to
older things not getting patched), would it be possible to have LEDE test
devices as they associate and record if they are vulnerable to this or not
(ideally, in a way that would let LUCI display this as an added column)
In concept, this is similar to the way ssh warns if you use a cert that may have
been created on the buggy debian version years ago.
David Lang
1 Like
wpa_disable_eapol_key_retries can't magically fix the clients, as they're the (most-) vulnerable element. All it can do is making it harder to exploit the vulnerability (by not following the requests to key retries) while the clients are connected to your wlan. This makes it a bit less likely that an attacker succeeds - but can't really prevent it - and it won't do anything when your (e.g.) phone is no longer in range/ connected to your AP, but roaming elsewhere.
There is no way around it that all clients must be fixed individually.
Any thoughts/opinions on that?
...it depends.
On linux, we do have most of the patches only touching hostapd/ wpa_supplicant code in userspace, but a small patch is also needed for the kernel (fixing the generic mac80211 stack). However there are differences of how much functionality drivers actually offload to the generic (kernelside-) stack and how much they do in the wlan chip (respectively the firmware running on the wlan chip) themselves. For the mainline linux wlan drivers, hostapd should indeed be the component to fix this in a generic way - for out-of-tree drivers the situation can be different (there are drivers like the closed source broadcom drivers or old RaLink wireless drivers which do all that in custom/ closed source code or their linux driver, those will need individual fixes).
For windows the situation is much less transparent, not just because those drivers aren't open source, but also because windows doesn't really have a direct equivalent to a generic wlan stack (like mac80211 on linux). NDIS5/ NDIS6 is just a rather high level API which still forces the individual drivers to do most of the connection handline inside their own driver and e.g. Intel is already shipping driver fixes for this vulnerability (also for their AMT functionality, how likely it'll be that mainboard vendors will actually push BIOS updates containing these AMT fixesā¦).
Embedded devices (think esp8266) is even further up this direction, as there is no generic software involved and each individual wlan firmware does require updating (Espressiv was surprisingly quick with this, however if all the vendors using their chips will actually deploy those upgradesā¦).
1 Like
I built latest LEDE from source exactly 7 hours ago, but it seems i have old packages in it. How can i get newer packages? I ran update feeds and installed them.
in the router when running
opkg update
opkg list-upgradable
i get this
Multiple packages (libstdcpp and libstdcpp) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc and libgcc) providing same name marked HOLD or PREFER. Using latest.
How can i compile with latest packages?
It sounds like you are somehow mixing things.
If you have compiled an image 7 hours ago after updating the feeds (and updating the main source with "git pull" too????), you should have up-to-date sources for everything.
- If you compile a new fresh firmware, the best practice is to include all packages you need into the image itself. Andf then you flash it with the up-to-date packages. And you need no opkg list-upgradable"
- opkg list-upgradable should usually not be used if you are compiling a private firmware. That can be used for some packages if you are using the release build, but if you are using a personal image, it is better to have everything in the image.
I did git clone, then git pull, then updated feeds then installed them. I always build my version with all the packages which i need 
and i flashed it. But still i have for example
wpad 2017-08-24-c2d4f2eb-3
hostapd-common 2017-08-24-c2d4f2eb-3
i guess these are not latest version right?
Those ARE the latest version in master.
See for yourself:
10 PKG_RELEASE:=3
11
12 PKG_SOURCE_URL:=http://w1.fi/hostap.git
13 PKG_SOURCE_PROTO:=git
14 PKG_SOURCE_DATE:=2017-08-24
15 PKG_SOURCE_VERSION:=c2d4f2eb5dba0b5c5a8c5805823084da958a9b52
1 Like
Sorry i got confused because of this post.
"The fix is available now. Update wpad (or wpad-mini) and hostapd-common to the latest version.
wpad - 2016-12-19-ad02e79d-5
hostapd-common - 2016-12-19-ad02e79d-5
"
Yesterday i was building that system late night until ~ 6 am 
suddenly i did not even think of the date. I just looked at month and it was newer then mine so i thought i had older version. Stupid me
Well, that is the stable 17.01 branch that has older hostapd (now patched to have the fix)...
If can be difficult to keep track that which branch a message is about. It happens 
1 Like
Would not be it easy if date was modified when the package is modified? Because when you look at it 2016-12-19 or 2017-08-24 it seems old, Although they include fix for 2017-10-XX WPA2 vulnerability.
Confirmed!
20.0.2 ReleaseNotes:
https://downloadmirror.intel.com/27215/eng/ReleaseNotes_WiFi_20_0_2.pdf
Among other fixes...
Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse. See www.intel[dot]com/security, INTEL-SA-00101 for more information.