Doea anyone know when is there going to be a security update for the recent wpa2 problem ?
It’s already available in 42.2-test and 42.3-test, SLE12 received patches already.
My guess; today.
I should really update machine from 42.1 to 42.2 but got no backup…
Well luckily you have us; I rebuilt the 42.2 patched version of wpa_supplicant for 42.1 here:
https://download.opensuse.org/repositories/home:/Miuku:/discontinued/openSUSE_Leap_42.1/
As usual the “Use at your own risk, I don’t have 42.1 but it should work just fine. You’ll have to vendor change there and please upgrade your boxes whenever possible” -clause applies 
Can this really be patched client-side only?
I haven’t been able to view an in-depth technical demo,
But, from the descriptions I’ve read, it seemed very much like a cousin to the Diffie Hellman key exchange flaw discovered and patched last year (that’s a 3-step handshake, Wifi is a 4-step handshake and the flaw is purported the third step).
Or, maybe the key randomization has changed?
Are there then both a “better than none” patch for clients and only when both AP and client are patched would the problem be fully addressed?
Skimming a published list of patches for different vendors, I see patches for both servers and clients…
TSU
It’s actually possible to “fix” the issue with a client side patch since the attack is aimed at it. You also have to patch any repeaters you have and possibly bridging devices.
Here’s a link to the way they fixed it in wpa_supplicant (and hostapd) and ways to mitigate the issue; http://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
Thx for the link…
Based on your reference and all IMO(Anyone can therfor laugh or insult any of my opinions as you like)…
As I theorized, there are largely two overall types of vulnerabilities based on the AP or the client(station) side and patching one side does not address the vulnerabilities of the other…
The AP side of course likely applies to practically every AP in existence… I can’t think of a single WiFi AP that isn’t likely based on some version of Linux/Unix… And it’s also further likely to be based on Busybox. For more about issues about Busybox and IoT, see a slide deck from my presentation last year (and re-presented several times since)
The main vulnerability related to APs seem to be packet replay, which is time-sensitive. The contents of the session remain encrypted and not likely crackable by the attacker before the session expires, but might not need to be cracked and could be exploitable by a MITM or similar attack, thereby taking over the connection.
Other AP theoretical vulnerabilities are described with little practical likelihood to be exploited.
From the description,
Although I’ve read how MS Windows clients might not be vulnerable (although MS has already released patches) my guess is that Windows station sessions would be affected even if Windows machines themselves are not hacked.
The client(station) vulnerabiities are more serious,
Several vulnerabilities and scenarios are described which disable packet authentication by resetting the client-side packet enumeration which is generally the primary way for TCP/IP session packets to be authenticated. This can possibly result in the attacker “resetting” the network connection and taking it over. For the moment, I can’t think of a way an attacker might eavesdrop on a connection instead. If the original User has an open session to a remote Internet site, depending on the network connection’s authentication and authorization I suppose some types of connections might be compromised, and the attacker might have immediate access.
IMO possible mitigation is that these attacks require capturing a very few specific packets issued when a handshake is done and must be cracked before the original User’s session has disconnected. So, networks where Users disconnect frequently and sessions are relatively short(particularly APs that issue rotating keys every few minutes) are less vulnerable whereas the converse would likely be true, if you have a large number of permanent Hosts which generate little traffic and rarely disconnect(sessions are longer) could be very vulnerable.
In both of the above types of vulnerabilities, the attacker would at the least potentially have some degree and possibly full access to LAN resources.
Of course,
Everything described here might be exploited only by an attacker with physical access to the WiFi signal, nothing described here is exploitable further away or over a non-wireless connection.
TSU
Windows was vulnerable too, they just patched it last week so they weren’t “counted as vulnerable anymore”. OpenBSD patched in July though so… they’re the Official Patch King.
Hello - is it reasonable for me to assume that Tumbleweed also is now patched pls?
Hi
Nope, Check the changelog?
cat /etc/os-release |grep VERSION_ID
VERSION_ID="20171017"
rpm -q --changelog wpa_supplicant | head -n 5
* Mon Oct 16 2017 meissner@suse.com
- Fix KRACK attacks (bsc#1056061, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13087, CVE-2017-13088):
- rebased-v2.6-0001-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch
- rebased-v2.6-0002-Prevent-reinstallation-of-an-already-in-use-group-ke.patch
- rebased-v2.6-0003-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch
Ugh, there’s still soooo much stuff i don’t know.
Not having had a clue about how to do that myself, i’ve now simply mimicked what you showed me:
gooeygirl@linux-Tower:~> cat /etc/os-release |grep VERSION_ID
VERSION_ID="20171007"
gooeygirl@linux-Tower:~> rpm -q --changelog wpa_supplicant | head -n 5
* Fri Apr 21 2017 obs@botter.cc
- fix wpa_supplicant-sigusr1-changes-debuglevel.patch to match
eloop_signal_handler type (needed to build eapol_test via config)
* Fri Dec 23 2016 dwaas@suse.com
gooeygirl@linux-Tower:~>
Am i correct to infer that currently i am not patched, but that when i dup to 20171017 i will be? Oh, no, that can’t be right either, coz you said
Nope,
Hmmmm.
Hi
The Nope was for not to assume anything 
So my Tumbleweed is patched, yours isn’t yet…
Your 3 or 4 snapshots behind…
Hi
So you have missed 20171009, 20171010, 20171013 and the latest 20171017…
Not so much missed per se, as rather declined to bother doing my usual weekly dup. Why? Coz last week someone [might have been you, might have been someone else] mentioned something like “Plasma 5.11.1 will be out on Tuesday”, & as i found stuff that does not work correctly in one of my test TW VMs that i had already upgraded to P5.11.0 as soon as it came available, i thought i’d just wait for 5.11.1 to arrive before duping my real TWs. Tues’ been & gone. I read the MLs each morning looking for news of it, but still have not seen it. If not here by Sat i shall have to dup anyway i suppose, just to not be too far behind.
This is totally OT. Not wanting to make you blush or anything, but… how the %^$@ do you know all this stuff? It’s amazing & i am constantly agog. You seem to know everything, & i feel constantly floundering. Thank goodness for your & the others’ generosity !!
Experience.
There’s nothing wrong with delaying updates. But when there is a fix for a known security issue, maybe it is time to bring your system up to date.
As a general principle i completely agree with you. In the present specific case, additional to what i already posted, my thinking was as follows.
- My primary pc is my Tower, & is in use all day every day, & often also long into many nights. This pc does not
have WiFi; it connects to my modem exclusively via Ethernet cable. Hence, i presumed that this important patch will not actually do anything useful on this pc. 1. My secondary pc is my Laptop. There are exceptions, but generally speaking this pc is left Suspended during daylight hours, & i only wake it at nights when i want to stream Netflix. It of course does
have WiFi, & that’s how i connect it to my modem. Hence it would appear that this pc should be prioritised for the dup to get the patch. Yet i still have not done it. I was intending to do it yesterday, but then i had the following, completely fatalistic pessimistic realisation. Even if/when my Lappy is patched, my WiFi modem remains unpatched, & unpatchable [by me, at least]. Hence, patching my Lappy’s WiFi does not actually protect me, does it? Why can’t a putative “bad person” still “war drive” around my neighbourhood, sniff my WiFi network, & break into it through the modem by the exploits recently revealed? That is, why is patching my Lappy helpful, if the modem remains vulnerable anyway? In other words, i depressingly concluded that “I’m stuffed”, until & unless i could afford to buy a better modem that is properly secure. 1. Is my logic defective? If yes, i would immediately do the dups
, even if not yet at my normal weekly interval.
You may commence your communal laughter at my silliness & ignorance, now. :shame:
Hi
Your system(s) your call, but if you look there is an update to 2071018 available, CVE’s in the list. You need to review the ML post, then decide if the package is installed whether to update.
Is the modem your’s or the ISP’s? If yours, does it support openWRT?
On Fri, 20 Oct 2017 01:56:02 +0000, malcolmlewis wrote:
> Is the modem your’s or the ISP’s? If yours, does it support openWRT?
Arguably, it’d not the modem - it’d be the router. <g>
(openWRT user here myself)
But my understanding of the WPA2 vuln is that it’s a client-side issue,
so a change at the router isn’t really going to address it. But I’ll be
the first to admit I don’t know everything about it, so I could be wrong
there (in which case, I need to get my router updated).
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C