Is it committed to the 17.01 branch? Which commit is the fix?
I see it now. It must be 7fc88b4e6e
Do you happen to have a link? I cannot seem to find it.
Can this be fixed by updating luci with opkg upgrade?
Here is the link https://git.lede-project.org/?p=project/luci.git;a=commit;h=7fc88b4e6eb8abf4b53f74f95306dd84b57e9a53
This will probably throw an error if there are no packages to upgrade. You might wanna add the "-r" switch to xargs, so it doesn't run opkg upgrade if there are now packages to upgrade. And the field seperator switch -F shouldn't be necessary either, since it will split on the space preceding the dash anyway (or following the package name, depending on the way you look at it), so this should do:
opkg list-upgradable | awk '{print $1}' | xargs -r opkg upgrade
That probably depends on which packages specifically you upgraded. For some it might be enough to just restart the service in question. Other changes, such as binary firmware packages, are only effective after a reboot. So, as a general rule of thumb, a reboot might be a good idea.
Not from the release. But you can build luci-mod-admin-full and install it using opkg.
Maybe if maintainers replace the package in the repos, it will be possible.
I guess so, opkg upgrade luci-mod-admin-full is probably enough once the updated pacakge is in the repo.
Alternatively head to "Admin -> System -> Software", enter luci-mod-admin-full after "Download and install package:" and click "Ok".
I don't think it will be in the 17.01.4 repo. Normally they don't update them. But you can probably do something about that.
Actually, I think that if you upgrade to 17.01.4 after the 17.01 packages buildbot has finished compiling current LuCI, you will get that updated package automatically. (The faulty luci-mod-admin-full in the release repo gets overwritten by the current version.)
You will also get the update if you build the 17.01 firmware now by yourself from the 17.01 branch HEAD, but you will NOT get it if you build from the 17.01.4 tag.
It will be in the repo.
Also it is possible to manually replace the /usr/lib/lua/luci/model/cbi/admin_network/wifi.lua file in the router.
A thanks to the devs for getting 17.0.1.4 out so quickly!
I know the article says that you shouldn't worry about the wireless password as it's more of a client, man in the middle attack. But with that said, wouldn't it be possible once you are the man in the middle to use a tool such as 'aireplay-ng' to run a deauth attack to get the eapol packets? At that point would the router's wireless password (sent by the client for authentication) be easily decrypted with the zero key, bypassing the need for a cracking tool on those captured packets such as 'aircrack-ng'? If this is the case it would open your devices up to much more easier and dangerous attacks than injections once the man in the middle has LAN access to the network.
The easiest way to get the Luci fix is to build from the v17.01.4 tag, but update feeds.conf.default with the Luci commit.
That's certainly not easy for normal users. The easiest way is to install the 17.01.4 firmware images that are available now and wait until the buildserver builds the updated luci version from git and uploads the new packages to the repository (should be done by tomorrow or the day after). Then update your package lists and upgrade to the new package versions. As jow mentioned before, new luci packages will be updloaded to the repository soon (and as one of the core developers he should know). Btw, there have been multiple updates to the luci packages during the 17.01 release lifecycle already that did not all require a new firmware image but merely a package upgrade.
Note: The updated luci packages that expose the new option wpa_disable_eapol_key_retries on the web interface are now available.
2 Likes
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.