LinuxQuestions.org - [SOLVED] Krack attack patched for stable and -current

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Krack attack patched for stable and -current (https://www.linuxquestions.org/questions/slackware-14/krack-attack-patched-for-stable-and-current-4175615937/)

Krack attack patched for stable and -current

Today's changelog.

Code:

Wed Oct 18 18:21:18 UTC 2017

ap/cups-2.2.5-x86_64-1.txz:  Upgraded.

n/wpa_supplicant-2.6-x86_64-2.txz:  Rebuilt.

  This update includes patches to mitigate the WPA2 protocol issues known

  as "KRACK" (Key Reinstallation AttaCK), which may be used to decrypt data,

  hijack TCP connections, and to forge and inject packets. This is the

  list of vulnerabilities that are addressed here:

  CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the

    4-way handshake.

  CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.

  CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way

    handshake.

  CVE-2017-13080: Reinstallation of the group key (GTK) in the group key

    handshake.

  CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group

    key handshake.

  CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT)

    Reassociation Request and reinstalling the pairwise encryption key (PTK-TK)

    while processing it.

  CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.

  CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS)

    PeerKey (TPK) key in the TDLS handshake.

  CVE-2017-13087: reinstallation of the group key (GTK) when processing a

    Wireless Network Management (WNM) Sleep Mode Response frame.

  CVE-2017-13088: reinstallation of the integrity group key (IGTK) when

    processing a Wireless Network Management (WNM) Sleep Mode Response frame.

  For more information, see:

    https://www.krackattacks.com/

    https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13077

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13078

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13079

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13080

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13081

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13082

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13084

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13086

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13087

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13088

  (* Security fix *)

x/libXfont2-2.0.2-x86_64-1.txz:  Upgraded.

  This update is a collection of minor fixes since 2.0.1, including

  CVE-2017-13720 and CVE-2017-13722.

  For more information, see:

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13720

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13722

  (* Security fix *)

x/libXres-1.2.0-x86_64-1.txz:  Upgraded.

  Integer overflows may allow X servers to trigger allocation of insufficient

  memory and a buffer overflow via vectors related to the (1)

  XResQueryClients and (2) XResQueryClientResources functions.

  For more information, see:

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1988

  (* Security fix *)

x/xorg-server-1.19.5-x86_64-1.txz:  Upgraded.

  This update fixes integer overflows and other possible security issues.

  For more information, see:

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12176

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12177

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12178

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12179

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12180

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12181

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12182

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12183

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12184

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12185

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12186

    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12187

  (* Security fix *)

x/xorg-server-xephyr-1.19.5-x86_64-1.txz:  Upgraded.

x/xorg-server-xnest-1.19.5-x86_64-1.txz:  Upgraded.

x/xorg-server-xvfb-1.19.5-x86_64-1.txz:  Upgraded.

+--------------------------+

does wireless need to be restarted once wpa_supplicant is upgraded? thanks

I would note this is only sorting part of the issue (the only part in slackware) you will also need to update the firmware in your router (if they have patched) to be secure.

Quote:

Originally Posted by tdos20 (Post 5771633)

I would note this is only sorting part of the issue (the only part in slackware) you will also need to update the firmware in your router (if they have patched) to be secure.

My #@*%ing router has yet to release updated firmware for this issue. :)

Had a look around and seems the lede have patched and have a release available - I'm still running openwrt so I might have to change to lede now:
https://github.com/lede-project/sour...d37cac447af19c

Quote:

Originally Posted by tdos20 (Post 5771633)

I would note this is only sorting part of the issue (the only part in slackware) you will also need to update the firmware in your router (if they have patched) to be secure.

Just wondering, my understanding is that KRACK Attacks were directed at the WPA2 client-side handshakes with the AP. Routers acting as repeaters or fast roaming (802.11r mesh) would be impacted too as they use client-side handshakes. Said another way, a stand-alone AP is less vulnerable particularly if it is not repeating or involved with fast roaming. Is that wrong or just too early to tell?

Quote:

Originally Posted by Chuck56 (Post 5771666)

Yes that is correct. If you patch all your clients then you can safely wait for updates to your router firmware (if it is ever updated by your manufacturer). However, if you can update your router firmware it will take care of this vuln for all your devices at once.

Your main concern should be your /mobile/ smart phone not being patched until the next Google or Apple update. From what I understand, Google is to release a fix in the next (November) update. This is mainly only an issue if you use public wifi, and whether you trust that restaurants, coffee shops, air ports etc have patched their access points to fix this vuln. I suggest you stick to 3g/4g data plans whenever possible if you are mobile because there is no guarantee such access points will /ever/ be patched.

Quote:

Originally Posted by mralk3 (Post 5771712)

Your main concern should be your /mobile/ smart phone not being patched until the next Google or Apple update.

Yes. I don't have a patch yet for my Samsung S7. I ensure that WiFi is turned off on my phone when I leave the house. I do take a small risk using WiFi at home with the S7, it is hopefully unlikely that bad guys will be close enough to mess with me.

Quote:

Originally Posted by hitest (Post 5771728)

My phone is a Samsung Galaxy S5. I hope it will get the fix too, but my wireless provider tends to lag behind with these things. It might be time to get a new phone these coming holidays. I take comfort in the fact that war driving isn't as common these days.

I was running a LinuxLinksys E3000 router but switched to a Raspberry Pi 3 running CentOS ARM this week. Call me paranoid. :D

EDIT: I meant Linksys E3000!

Question for All'Y'All who know more than I ...

In addition to the new version of wpa_supplicant that I updated this morning ( ! Thanks Pat and Crew ! ), should I be watching for a firmware update for the Wireless Card in my Laptop ?

Thanks !

-- kjh

Code:

# lspci -v -n -n



<<snip>>



3f:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)

        Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network Adapter [1a56:1535]

        Flags: bus master, fast devsel, latency 0, IRQ 141

        Memory at dc200000 (64-bit, non-prefetchable) [size=2M]

        Capabilities: [40] Power Management version 3

        Capabilities: [50] MSI: Enable+ Count=8/8 Maskable+ 64bit-

        Capabilities: [70] Express Endpoint, MSI 00

        Capabilities: [100] Advanced Error Reporting

        Capabilities: [148] Virtual Channel

        Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00

        Capabilities: [178] Latency Tolerance Reporting

        Capabilities: [180] L1 PM Substates

        Kernel driver in use: ath10k_pci

        Kernel modules: ath10k_pci

Quote:

Originally Posted by tdos20 (Post 5771633)

I would note this is only sorting part of the issue (the only part in slackware) you will also need to update the firmware in your router (if they have patched) to be secure.

My old Linksys WRT54G was according to Cisco "no longer supported for updates including security", so I attempted to flash DD-WRT to it...it became a brick because my version v.8 is almost impossible to flash apparently.

So I upgraded to Netgear Opensource version, and guess what, it had an update as soon as I set it up. Geez, and how was I living with 54mps, this new router flies!!!!!!
https://www.amazon.com/NETGEAR-WNR35...+source+router
https://www.myopenrouter.com/

Netgears post about KRACK:
https://kb.netgear.com/000049498/Sec...-PSV-2017-2837

Quote:

Originally Posted by ChuangTzu (Post 5771806)

My old Linksys WRT54G ... it became a brick because my version v.8 is almost impossible to flash apparently.

No doubt that it was probably time to upgrade your router hardware, but if you still have it you might be able to fix it,

link to original post here.

Quote:

Router/Version: Linksys WRT54Gv8.0
Firmware: DD-WRT v3.0-r33525 micro (10/17/17) (Broadcom generic) ftp://ftp.dd-wrt.com/betas/2017/10-1...ro_generic.bin
Kernel: Linux 2.4.37 #46965 Tue Oct 17 05:11:42 CEST 2017 mips
Previous: BS r33492 (for about a day); DD-WRT v24-sp2 (01/16/10) micro (SVN revision 13637) for years before that
Mode/Status: AP/Working
Reset: followed update instructions on wiki (http://dd-wrt.com/wiki/index.php/Lin...8.0_%26_v8.2); did firmware flash via webgui; chose "don't reset" option for "After flashing, reset to"
Issues/Errors: The AP configuration instructions told me to disable the SPI firewall. But a JavaScript error on Firewall.asp prevented this. This isn't a new issue; it also existed in r33492 (but not r13637). Others reported this issue in 2014. The error exists because the submitcheck JS function wants to check the value of log_enable, but for micro builds the log_enable radio buttons are commented out. I think I found a workaround (http://www.dd-wrt.com/phpBB2/viewtop...276771#1099695).

You would probably need to jtag it though. Just something to play with if you have the time/desire. You need to flash it with v24 pre SP2 Build 14896 first before upgrading it to the latest (r33525). The Broadcom SoC "peacock thread" (sticky announcement) has all the info you need.

Quote:

Originally Posted by Skaendo (Post 5771824)

No doubt that it was probably time to upgrade your router hardware, but if you still have it you might be able to fix it,

link to original post here.

You would probably need to jtag it though. Just something to play with if you have the time/desire. You need to flash it with v24 pre SP2 Build 14896 first before upgrading it to the latest (r33525). The Broadcom SoC "peacock thread" (sticky announcement) has all the info you need.

Its on my to do list, for now it sits in a box with other old tech to play with at a later date. ;) Back in the day I used to use a double router/wall setup, its a bit overkill but was fun knowing someone would have to break the first to find out they were blocked by another.

Linksys posted updated firmware this morning, 20 October 2017, but dated, at least for my particular model, 17 October 2017.

Quote:

Originally Posted by cwizardone (Post 5772144)

Linksys posted updated firmware this morning, 20 October 2017, but dated, at least for my particular model, 17 October 2017.

Nice. Just checked my router's firmware. Nothing posted yet for my Asus. At least all of my PCs, laptops, and tablets are okay (not my phone).