As far as I understand, both routers and clients need to be patched to neutralize this in any particular networks. But I am going to bet my DD-WRT router is going to be patched way sooner than my smartphones, laptops and OSes...
Its great news that the bug is being patched, but unfortunately it will take some time before the update is available as installable firmware (im on asus rt-n13u (first version).
So is there any way for me to patch an existing installation, or possibly the firmware update .bin-file?
Its great news that the bug is being patched, but unfortunately it will take some time before the update is available as installable firmware (im on asus rt-n13u (first version).
So is there any way for me to patch an existing installation, or possibly the firmware update .bin-file?
Yes: compiling a DD-WRT build (code is public). But, be warned: compiling DD-WRT is very difficult for beginners. And even if you succeed, there is no guarantee that the build will work for your device. _________________ 2 times APU2 Opnsense 21.1 with Sensei
2 times RT-AC56U running DD-WRT 45493 (one as Gateway, the other as AP, both bridged with LAN cable)
3 times Asus RT-N16 shelved
E4200 V1 running freshtomato 2020.8 (bridged with LAN cable)
3 times Linksys WRT610N V2 converted to E3000 and 1 original E3000 running freshtomato 2020.8 (bridged with LAN cable)
Thanks. I do not understand the codes enough to appreciate how much this changeset has patched. BS hasn't hinted at a particular CVE in the comment, but it feels hopeful all of these seem related to the and wpa and wpa_auth codes.
I can see snippets like: wpa_auth_sta_ft_tk_already_set(sta->wpa_sm) ...
Do these change effectively force a re-key with new handshake everytime clients reconnect?
Any guestimates how long it will take for an official update?
Days? weeks? months?
Im sincerely grateful that folks are devoting their time and effort in making a free firmware for my router and i really dont want to be the nagging S.o.B, but its kind of a big deal, not having a network security..
Especially since i´ll get punished by law if someone else does some bad shit thru my wifi..
i read somewhere that the vulnerability needs to be fixed booth on router and on clients, is this true?
Its great news that the bug is being patched, but unfortunately it will take some time before the update is available as installable firmware (im on asus rt-n13u (first version).
Well, it'll be in the next build, which I'd suspect will be soon (in the next week), so keep an eye on ftp://ftp.dd-wrt.com/betas/2017/
to grab it from the /asus-rtn13u/ directory.
Of course as you know, monitor the appropriate New Build thread to make sure there isn't an issue first. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Thanks. I do not understand the codes enough to appreciate how much this changeset has patched. BS hasn't hinted at a particular CVE in the comment, but it feels hopeful all of these seem related to the and wpa and wpa_auth codes.
I can see snippets like: wpa_auth_sta_ft_tk_already_set(sta->wpa_sm) ...
Do these change effectively force a re-key with new handshake everytime clients reconnect?
Looks like the state tracking is fixed during rekey to mark when the new PTK is installed.
Looks like the state tracking is fixed during rekey to mark when the new PTK is installed.
Thanks. Do you know the behavior when the new PTK installation is detected? Does it basically reset and forcibly regenerate a new PTK?
And, what happens if there is not a new PTK installation? (somehow I got the impression that the point of this KRACK is the same secret and be used over and over and over again even for new client/AP handshake -- but honestly I do not fully understand it).
Looks like the state tracking is fixed during rekey to mark when the new PTK is installed.
Thanks. Do you know the behavior when the new PTK installation is detected? Does it basically reset and forcibly regenerate a new PTK?
And, what happens if there is not a new PTK installation? (somehow I got the impression that the point of this KRACK is the same secret and be used over and over and over again even for new client/AP handshake -- but honestly I do not fully understand it).
Without getting into too much detail, this code implements the recommendations made in the research paper.
The primary change to note is that the code now keeps track of the TK being installed so that duplicate "message 3" (3/4 of the handshake) do not result in multiple installations of the same key, which is how the replay counter was being reset. Instead, the code simply skips the duplicate key installation and responds back with message 4, as the 802.11i spec requires.
Looks like the state tracking is fixed during rekey to mark when the new PTK is installed.
Thanks. Do you know the behavior when the new PTK installation is detected? Does it basically reset and forcibly regenerate a new PTK?
And, what happens if there is not a new PTK installation? (somehow I got the impression that the point of this KRACK is the same secret and be used over and over and over again even for new client/AP handshake -- but honestly I do not fully understand it).
Without getting into too much detail, this code implements the recommendations made in the research paper.
The primary change to note is that the code now keeps track of the TK being installed so that duplicate "message 3" (3/4 of the handshake) do not result in multiple installations of the same key, which is how the replay counter was being reset. Instead, the code simply skips the duplicate key installation and responds back with message 4, as the 802.11i spec requires.
Thank you! This is a plenty clear high-level explanation (I won't understand enough to appreciate the details - thanks for summing the key points up).
