KCRACK vulnerability heads up

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2
Author Message
slobodan
DD-WRT Guru


Joined: 03 Nov 2011
Posts: 1555
Location: Zwolle

PostPosted: Mon Oct 16, 2017 20:23    Post subject: Reply with quote
dragonC wrote:
There is an updated build in <Kong>'s Test area. Not sure if it contains the patch:
http://desipro.de/ddwrt/K3-AC-Arm/TEST/

Yup, build 33525M (therefore, it includes the patch).

_________________
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)


Sponsor
wangmaster
DD-WRT Novice


Joined: 10 May 2011
Posts: 16

PostPosted: Mon Oct 16, 2017 21:27    Post subject: Reply with quote
xpxp2002 wrote:
dragonC wrote:
xpxp2002 wrote:
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.


I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?
dragonC
DD-WRT User


Joined: 23 May 2015
Posts: 272

PostPosted: Mon Oct 16, 2017 21:43    Post subject: Reply with quote
wangmaster wrote:
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?


Good question - I'd like to know too. From xpxp2002's explanation I'd assume the handshake fix is on the AP-side (no way DD-WRT can reliably tell the client what to do based on states it tracks, right?).

In other words, does this mean a AP-side fix is sufficient (i.e. no client side patch needed) to mitigate all of these listed CVEs?
quarkysg
DD-WRT User


Joined: 03 May 2015
Posts: 323

PostPosted: Mon Oct 16, 2017 21:46    Post subject: Reply with quote
From what I can tell, ‘hostapd’ is not used by the dd-wrt firmware (at least for the BCM SOCs) but rather the proprietary ‘nas’ utility for access point functionality.

Anyone in the know can comment on this?
wangmaster
DD-WRT Novice


Joined: 10 May 2011
Posts: 16

PostPosted: Mon Oct 16, 2017 21:59    Post subject: Reply with quote
dragonC wrote:
wangmaster wrote:
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?


Good question - I'd like to know too. From xpxp2002's explanation I'd assume the handshake fix is on the AP-side (no way DD-WRT can reliably tell the client what to do based on states it tracks, right?).

In other words, does this mean a AP-side fix is sufficient (i.e. no client side patch needed) to mitigate all of these listed CVEs?


The more I read about it, I'm not sure what a router can actually do. Yuck. This kinda sucks because I have an ancient WRT-HP-54G running some 14xxx or 15xxx build acting as a wireless bridge.
slobodan
DD-WRT Guru


Joined: 03 Nov 2011
Posts: 1555
Location: Zwolle

PostPosted: Mon Oct 16, 2017 23:12    Post subject: Reply with quote
dragonC wrote:
wangmaster wrote:
I'm not very familiar with the hostap code. Is this actually fixing it for client-mode or is this actually implementing the AP side mitigation for KRACK as well?


Good question - I'd like to know too. From xpxp2002's explanation I'd assume the handshake fix is on the AP-side (no way DD-WRT can reliably tell the client what to do based on states it tracks, right?).

In other words, does this mean a AP-side fix is sufficient (i.e. no client side patch needed) to mitigate all of these listed CVEs?

Q&A wrote:
Do we now need WPA3?

No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available.

_________________
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)


wangmaster
DD-WRT Novice


Joined: 10 May 2011
Posts: 16

PostPosted: Mon Oct 16, 2017 23:22    Post subject: Reply with quote
slobodan wrote:

Q&A wrote:
Do we now need WPA3?

No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available.


The krackattacks Q&A also has this:
Quote:
What if there are no security updates for my router?

Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.


I'm not entirely clear what it means to "patch" the access point unless you're talking about an access point as a client.
jwh7
DD-WRT Guru


Joined: 25 Oct 2013
Posts: 2670
Location: Indy

PostPosted: Mon Oct 16, 2017 23:48    Post subject: Reply with quote
wangmaster wrote:
slobodan wrote:

Q&A wrote:
Do we now need WPA3?
[...] In other words, a patched client or access point sends exactly the same handshake messages as before, and at exactly the same moment in time. [...]
The krackattacks Q&A also has this:
Quote:
What if there are no security updates for my router?

[...] you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
I'm not entirely clear what it means to "patch" the access point unless you're talking about an access point as a client.
They are using layman's terms for client->user and access point->router. But from the above, it sounds like only router modes for Repeater and Client are vulnerable to the 3rd step in the handshake exchange.
_________________
# 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
wangmaster
DD-WRT Novice


Joined: 10 May 2011
Posts: 16

PostPosted: Tue Oct 17, 2017 0:02    Post subject: Reply with quote
jwh7 wrote:
They are using layman's terms for client->user and access point->router. But from the above, it sounds like only router modes for Repeater and Client are vulnerable to the 3rd step in the handshake exchange.


That's my read on it too, but I've also seen comments elsewhere that it should be possible to detect the vulnerable clients and the key reinstallation attempts but I wasn't clear if the patches brainslayer pulled in attempts to do that. my quick read of it seems that it doesn't but I'm not even remotely close to familiar with hostapd's code.

Interestingly, looking at hostapd's commit log This was pushed about 3 hours ago:
https://w1.fi/cgit/hostap/commit/?id=6f234c1e2ee1ede29f2412b7012b3345ed8e52d3

It seems to be what I'm referring to (base station workaround for vulnerable devices) but it apparently has some potential downsides.
Whammy
DD-WRT User


Joined: 14 Aug 2007
Posts: 50

PostPosted: Tue Oct 17, 2017 0:39    Post subject: Reply with quote
jwh7 wrote:
More details for hostapd:
https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
xarvox wrote:
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. Smile


What about devices who can't flash a build because the file size is too big?
vinnie97
DD-WRT User


Joined: 30 Jan 2009
Posts: 86

PostPosted: Tue Oct 17, 2017 7:55    Post subject: Reply with quote
Yes, I'm using the WNDR4000 so will the patch include future K2 builds? I've been using a K2 build since 2013 and have no desire to jump to K3 if it's not necessary.

The latest betas have no folder for the WNDR4000 so that's also a concern: ftp://ftp.dd-wrt.com/betas/2017/

Forgive my ignorance on the issue, as I'm rather behind the times.

EDIT: I simply need to upgrade to the Broadcom K26 build (I.e. dd-wrt.v24-33492_NEWD-2_K2.6_mega-nv64k.bin) in order to avoid any K3 size nightmares, correct?

ftp://ftp.dd-wrt.com/betas/2017/10-10-2017-r33492/broadcom_K26/

Once r33525 arrives, I should be golden.
dragonC
DD-WRT User


Joined: 23 May 2015
Posts: 272

PostPosted: Tue Oct 17, 2017 15:11    Post subject: Reply with quote
quarkysg wrote:
From what I can tell, ‘hostapd’ is not used by the dd-wrt firmware (at least for the BCM SOCs) but rather the proprietary ‘nas’ utility for access point functionality.

Anyone in the know can comment on this?


Hi all,

May I know if there's any knowledge on whether BCM SoCs are covered by BS's patch? I myself own R7000 and R6300v2 -- but I believe answer to this would be of interest to the general audience in this (Broadcom) forum.

BS's newer commit #33526 ( http://svn.dd-wrt.com/changeset/33526 ) also updated hostapd to newer version -- but it seems from this diff alone only atheros (i.e. ATH10K) are using the newer, patched 2016-09-05 version, while the rest still falls back to 2014-06-03 or 2014-10-25.
jwh7
DD-WRT Guru


Joined: 25 Oct 2013
Posts: 2670
Location: Indy

PostPosted: Tue Oct 17, 2017 16:32    Post subject: Reply with quote
quarkysg, that's a good question. Maybe BS or Kong will comment here.
dragonC wrote:
May I know if there's any knowledge on whether BCM SoCs are covered by BS's patch? [...]
BS's newer commit #33526 ( http://svn.dd-wrt.com/changeset/33526 ) also updated hostapd to newer version -- but it seems from this diff alone only atheros (i.e. ATH10K) are using the newer, patched 2016-09-05 version, while the rest still falls back to 2014-06-03 or 2014-10-25.
So it appears that ath10k has the newer patched hostapd from 33526, while everything else uses the older patched hostapd from 33525. But they are both patched for krack.
_________________
# 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
jwh7
DD-WRT Guru


Joined: 25 Oct 2013
Posts: 2670
Location: Indy

PostPosted: Tue Oct 17, 2017 19:22    Post subject: Reply with quote
Kong just discussed this in his build thread:
<Kong> wrote:
mac913 wrote:
christian1980nrw wrote:
Is this WPA2 Krack Hotfix already integrated?
http://svn.dd-wrt.com/changeset/33525

Changeset 33525 does show fixes Krack Issues with wpa retransmission.

But, looking at the changsets the Krack HotFix was fixed on 33526 on Oct 17...
http://svn.dd-wrt.com/changeset/33526

But it looks to update hostapd for Qualcomm Atheros. Is Broadcom fine or more to come?

It does not make sense to read commit messages if you do not understand them.

The change in 33526 only switches some older targets, to the patched version from yesterday.

Units like Marvel/IPQ have always been on our latest hostapd, which he already fixed yesterday:-)

If you look at:
http://svn.dd-wrt.com/browser/src/router

you will see the different hostapd versions, some older targets still used the older hostapd versions.

_________________
# 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
jwh7
DD-WRT Guru


Joined: 25 Oct 2013
Posts: 2670
Location: Indy

PostPosted: Mon Oct 23, 2017 17:06    Post subject: nas vs hostapd Reply with quote
quarkysg wrote:
From what I can tell, ‘hostapd’ is not used by the dd-wrt firmware (at least for the BCM SOCs) but rather the proprietary ‘nas’ utility for access point functionality.

Anyone in the know can comment on this?
BS replied to one of the tickets about it:
BrainSlayer on SVN wrote:
nas is not used for the real supplicant work. the authentication is within the driver itself. and for devices with a own on chipset firmware like the newer dhd drivers, we need complete new firmware blobs
Fixes are in:
    Changeset [33574] by brainslayer: update for older broadcom devices
    Changeset [33573] by brainslayer: fix for krackattack
    Changeset [33572] by brainslayer: fix for broadcom supplicant to handle krackattack
Also see here: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1100282#1100282

_________________
# 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
Goto page Previous  1, 2 Display posts from previous:    Page 2 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum