Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?

[harry newton]

Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
<https://www.krackattacks.com>

I reported it yesterday over here with links...
<https://groups.google.com/forum/#!forum/alt.internet.wireless>

They made it public a half hour ago:
<https://groups.google.com/d/msg/alt.internet.wireless/vn8yRnm7UF8/N89Wcd_OAAAJ>

Manufacturers apparently had 50 days to effect the fix:
Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2
<https://papers.mathyvanhoef.com/ccs2017.pdf>

--
No need to respond; this is just FYI...

[harry newton]

The weaknesses are in the Wi-Fi standard itself, and not in individual
products or implementations.

Therefore, any correct implementation of WPA2 is likely affected. To
prevent the attack, users must update affected products as soon as security
updates become available.

If your device supports Wi-Fi, it is most likely affected.

Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are
all affected by some variant of the attacks.

The research behind the attack will be presented at the Computer and
Communications Security (CCS) conference, and at the Black Hat Europe
conference. Our detailed research paper can already be downloaded.

DEMONSTRATION
As a proof-of-concept we executed a key reinstallation attack against an
Android smartphone.

In this demonstration, the attacker is able to decrypt all data that the
victim transmits. For an attacker this is easy to accomplish, because our
key reinstallation attack is exceptionally devastating against Linux and
Android 6.0 or higher.

This is because Android and Linux can be tricked into (re)installing an
all-zero encryption key (see below for more info). When attacking other
devices, it is harder to decrypt all packets, although a large number of
packets can nevertheless be decrypted.

In any case, the following demonstration highlights the type of information
that an attacker can obtain when performing key reinstallation attacks
against protected Wi-Fi networks:

Any data or information that the victim transmits can be decrypted.

Additionally, depending on the device being used and the network setup, it
is also possible to decrypt data sent towards the victim (e.g. the content
of a website).

Although websites or apps may use HTTPS as an additional layer of
protection, we warn that this extra protection can (still) be bypassed in a
worrying number of situations. For example, HTTPS was previously bypassed
in non-browser software, in Apple's iOS and OS X, in Android apps, in
Android apps again, in banking apps, and even in VPN apps.

[David_B]

FYI https://www.krackattacks.com/

--
David B.

[harry newton]

He who is David_B said on Mon, 16 Oct 2017 15:13:58 +0100:

> FYI https://www.krackattacks.com/

That link was already in the original post. :)

In cryptography, a nonce is a neologism for an arbitrary number that may
only be used once, similar in spirit to the occasionalism lexeme "nonce
word" (as are the headwords of any dictionary).

Here is a related link to the Blackhat briefing that wasn't in the OP:
<https://www.blackhat.com/eu-17/briefings/schedule/#key-reinstallation-attacks-breaking-the-wpa2-protocol-8861>

"We have discovered several key management vulnerabilities in the Wi-Fi
Protected Access II (WPA2) security protocol. These can be exploited using
so-called key reinstallation attacks.

Because this is a protocol-level issue, most correct implementations of the
standard are affected.

Put differently, most protected Wi-Fi networks, including personal and
enterprise WPA2 networks, are affected.

All clients and access points that we tested in practice were vulnerable to
some variant of the attack. The precise impact depends on the specific
variant(s) of the attack that an implementation is vulnerable to."

Bear in mind that the attacker has to be in close proximity to your device
to effect the attack, and that no known variants are in the wild yet, so
it's not something to worry about except to start looking for when the
patches come out for all your devices that handle the WiFi WPA2/PSK
protocol.

--
See also en.wikipedia.org/wiki/Cryptographic_nonce

[Mr. Man-wai Chang]

On 16/10/2017 8:46 PM, harry newton wrote:
> Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
> <https://www.krackattacks.com>
>
> I reported it yesterday over here with links...
> <https://groups.google.com/forum/#!forum/alt.internet.wireless>

> ...

Did you notice that these hacks always happen BEFORE someone fixed it?
Are they all security traps, planted into router firmware by design? :)

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[pf...@aol.com]

On Monday, October 16, 2017 at 11:57:56 AM UTC-4, Mr. Man-wai Chang wrote:

> Did you notice that these hacks always happen BEFORE someone fixed it?
> Are they all security traps, planted into router firmware by design? :)

a) If the fix were in, then they could not happen.
b) Otherwise, it would not be a Hack.

You need to brush up on your logic.

Peter Wieck
Melrose Park, PA

[harry newton]

He who is Mr. Man-wai Chang said on Mon, 16 Oct 2017 23:57:50 +0800:

> Did you notice that these hacks always happen BEFORE someone fixed it?
> Are they all security traps, planted into router firmware by design? :)

This nonce KRACK vulnerability is in *everything*, including smart phones
(iOS & Android) and computers (Mac/Windows/Linux) and routers
(Netgear/Cisco/TPLink) ....

It even affects web sites (e.g., Match.com)...

It's more than just routers, so it's *big* - but bear in mind
a. Fixes will be out soon
b. Nothing is known in the wild yet
c. You have to be nearby to be vulnerable

Still, since it affects *everything* using WPA2 (business and personal),
it's a big deal nonetheless.

All you can do is wait for the patch when it comes out for each of your
devices that implement the affected encryption protocol.

[Bill Bradshaw]

It appears if you do not use or have WiFi and WPS enabled you should be
secure from this. Since I have both disabled I assume I am safe because I
use neither.
---
<Bill>

Brought to you from Anchorage, Alaska

"harry newton" <ha...@is.invalid> wrote in message
news:os29mf$19go$1...@gioia.aioe.org...

[harry newton]

He who is Bill Bradshaw said on Mon, 16 Oct 2017 09:23:19 -0800:

> It appears if you do not use or have WiFi and WPS enabled you should be
> secure from this. Since I have both disabled I assume I am safe because I
> use neither.

More so than routers, mostly all known wifi "clients" are affected (e.g.,
all consumer smartphones and computers) that use either WPA or WPA2
(enterprise or personal), and even against networks that just use AES.

Some encrypted web sites are also affected, such as Match.com (as shown in
the aforementioned video).

So you're right that it's not a big deal that there is no encryption in all
these cases because the the man in the middle has to be nearby.

[s|b]

On Mon, 16 Oct 2017 12:46:08 +0000 (UTC), harry newton wrote:

> Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
> <https://www.krackattacks.com>

Still waiting for an update for my TP-Link Archer C7 router. If I
understand all this correctly, then I'll also need an update for my
Nexus 5X?

--
s|b

[J.O. Aho]

On 10/16/17 20:00, harry newton wrote:
> He who is Bill Bradshaw said on Mon, 16 Oct 2017 09:23:19 -0800:
>
>> It appears if you do not use or have WiFi and WPS enabled you should
>> be secure from this.  Since I have both disabled I assume I am safe
>> because I use neither.
>
> More so than routers, mostly all known wifi "clients" are affected (e.g.,
> all consumer smartphones and computers) that use either WPA or WPA2
> (enterprise or personal), and even against networks that just use AES.
>
> Some encrypted web sites are also affected, such as Match.com (as shown in
> the aforementioned video).

They do use a tool commonly used in man-in-the-middle attacks, to strip
away the tls and send the content to the client machine unencrypted. As
they did explain in the video, many don't check in their mobile devices
that they have tls communication or not and those they will be able to
carry out the attack to see the the login credentials in this example.

This has nothing to do with KRACK itself.

> So you're right that it's not a big deal that there is no encryption in all
> these cases because the the man in the middle has to be nearby.

There are devices that can give an attacker quite long range to execute
their attacks on, so you ain't safe just for you don't see anyone nearby.

--

//Aho

[J.O. Aho]

It's more important to update the client than the server.

[William Unruh]

I think, but do not know for sure, that the primary thing that needs to
protected is the client not the Access point. Ie, your Android (do they
use wpa_supplicant, since Android is based on Linux?) IOs , or your
laptop.
As far as I have seen, there is no fix out yet for wpa_supplicant.

It seems that the reason Windows is more resistant is because they did
not no impliment the full spec for WPA2.

[Roger Blake]

On 2017-10-16, J.O. Aho <us...@example.net> wrote:
> It's more important to update the client than the server.

Is this something that MS can push an update out for to fix, or does the
wifi chip vendor need to fix device firmware or device driver?

--
-----------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

NSA sedition and treason -- http://www.DeathToNSAthugs.com
Don't talk to cops! -- http://www.DontTalkToCops.com
Badges don't grant extra rights -- http://www.CopBlock.org
-----------------------------------------------------------------------------

[harry newton]

He who is J.O. Aho said on Mon, 16 Oct 2017 21:08:48 +0200:

> They do use a tool commonly used in man-in-the-middle attacks, to strip
> away the tls and send the content to the client machine unencrypted. As
> they did explain in the video, many don't check in their mobile devices
> that they have tls communication or not and those they will be able to
> carry out the attack to see the the login credentials in this example.
>
> This has nothing to do with KRACK itself.

Thanks for explaining *how* they manage to unencrypt *some* encrypted web
sites but not others, as I wasn't sure how they did that.

I was wrong in assuming it was the KRACK attack, which seems to be that
they simply hijack the third of the four handshakes, usually from the
client side, and force it to be resent where in some cases, it's resent as
all zeroes where in other cases it's just resent as a known nonce.

Is that a decent summary or can you summarize the attack mode better?

[harry newton]

He who is William Unruh said on Mon, 16 Oct 2017 19:58:55 -0000 (UTC):

> It seems that the reason Windows is more resistant is because they did
> not no impliment the full spec for WPA2.

Thanks for explaining that as this nonce stuff has certain unexpected
nuances.

However, we have to be a bit careful with any early conclusions such as
mine yesterday (before the paper came out) that routers were originally
involved more so than clients, which turns out, as noted, to be not the
case - the mobile device and desktop clients are the weak link here.

However, all conclusions from the paper at the moment are preliminary
because the paper was sent for review on the 19th May where the authors
found out more information afterward that's not in the paper, but it *does*
seem that some OS'es (e.g., MacOS & Android 6+ & Ubuntu, for example) are
apparently far more acutely affected than are the Windows based WPA1 and
WPA1 implementations (or the iOS implementation).

[Jonathan N. Little]

Ubuntu just pushed out a patch today.

sudo apt-get update && sudo apt-get -y upgrade

and you are good to go.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[harry newton]

He who is Jonathan N. Little said on Mon, 16 Oct 2017 18:13:09 -0400:

> Ubuntu just pushed out a patch today.
>
> sudo apt-get update && sudo apt-get -y upgrade
>
> and you are good to go.

We have to be careful about "a patch" since there are actually multiple
vulnerabilities, although perhaps one patch fixes all.

Ubiquiti released this today for example...where my rooftop radios can pick
up the signals from over a million people, so, that many people can attack
me. :)

"You are mostly covered if you are running v8.4.0 (AC series) or v6.0.7 (M
series). We will fully resolve the issue with v8.4.2/v6.1.2 (betas aimed
for the end of this week). Furthermore, our proprietary airMAX protocol
makes simple attacks more difficult to carry out.

Will be fully fixed with v8.4.2/v6.1.2:
CVE-2017-13077: reinstallation of the pairwise key in the Four-way
handshake
CVE-2017-13078: reinstallation of the group key in the Four-way handshake
CVE-2017-13079: reinstallation of the integrity group key in the Four-way
handshake
CVE-2017-13080: reinstallation of the group key in the Group Key handshake
CVE-2017-13081: reinstallation of the integrity group key in the Group Key
handshake
Unaffected:
CVE-2017-13082: accepting a retransmitted Fast BSS Transition Reassociation
Request and reinstalling the pairwise key 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"

[Paul]

Roger Blake wrote:
> On 2017-10-16, J.O. Aho <us...@example.net> wrote:
>> It's more important to update the client than the server.
>
> Is this something that MS can push an update out for to fix, or does the
> wifi chip vendor need to fix device firmware or device driver?
>

Fixed on Patch Tuesday. Good luck collecting
detailed proof though.

https://social.technet.microsoft.com/Forums/en-US/e2fe0489-93ae-4177-8dea-53e7a204ef54/eta-of-patch-for-quotkrackquot-was-this-patched-previously-or-should-we-expect-a-patch-soon?forum=win10itprosecurity

There's a Wifi architecture diagram here. This is so
you can see the degrees of freedom allowed.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/native-802-11-software-architecture

I'd wait for some "expert" opinion. I'd accept the
opinion of the Microsoft staffer who wrote the patch :-)
Anyone else, not so much.

Paul

[. . .winston]

Microsoft CVE Notice

<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080>
<qp>When did Microsoft release the security updates to address this
vulnerability?
Microsoft released security updates on October 10, 2017 as part of Update
Tuesday to resolve this vulnerability in all affected editions of Windows.
Customers who have Windows Update enabled and who applied the latest
security updates are protected automatically. The Security Update Guide was
updated on October 16, 2017 to provide full disclosure on this vulnerability
in accordance with a multi-vendor coordinated disclosure.
</qp>

Also, if using a NetGear router see....
<https://kb.netgear.com/000049498/Security-Advisory-for-WPA-2-Vulnerabilities-PSV-2017-2826-PSV-2017-2836-PSV-2017-2837>
</qp>
NETGEAR is aware of WPA-2 security vulnerabilities that affect NETGEAR
products that connect to WiFi networks as clients. These vulnerabilities are
potentially exploitable under the following conditions:
•Your devices are only vulnerable if an attacker is in physical proximity to
and within wireless range of your network.
•****Routers and gateways are only affected when in bridge mode**** (which
is not enabled by default and not used by most customers). A WPA-2 handshake
is initiated by a router in bridge mode only when connecting or reconnecting
to a router
</qp>


--
...winston
msft mvp windows experience 2007-2016, insider mvp 2016-2018

[harry newton]

He who is harry newton said on Mon, 16 Oct 2017 22:03:42 +-0000 (UTC):

> Thanks for explaining that as this nonce stuff has certain unexpected
> nuances.

Here's every patch for KRACK Wi-Fi vulnerability available right now
<http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/>

Apple: The iPhone and iPad maker confirmed to sister-site CNET that fixes
for iOS, macOS, watchOS and tvOS are in beta, and will be rolling it out in
a software update in a few weeks.

MORE SECURITY NEWS

WPA2 security flaw puts almost every Wi-Fi device at risk of hijack,
eavesdropping
Homeland Security orders federal agencies to start encrypting sites, emails
+IAs-OnePlus dials back data collection after users protest
These fake tax documents spread jRAT malware
Arris: a spokesperson said the company is "committed to the security of our
devices and safeguarding the millions of subscribers who use them," and is
"evaluating" its portfolio. The company did not say when it will release
any patches.

Aruba: Aruba has been quick off the mark with a security advisory and
patches available for download for ArubaOS, Aruba Instant, Clarity Engine
and other software impacted by the bug.

AVM: This company may not be taking the issue seriously enough, as due to
its "limited attack vector," despite being aware of the issue, will not be
issuing security fixes "unless necessary."

Cisco: The company is currently investigating exactly which products are
impacted by KRACK, but says that "multiple Cisco wireless products are
affected by these vulnerabilities."

"Cisco is aware of the industry-wide vulnerabilities affecting Wi-Fi
Protected Access protocol standards," a Cisco spokesperson told ZDNet.
"When issues such as this arise, we put the security of our customers first
and ensure they have the information they need to best protect their
networks. Cisco PSIRT has issued a security advisory to provide relevant
detail about the issue, noting which Cisco products may be affected and
subsequently may require customer attention.

"Fixes are already available for select Cisco products, and we will
continue publishing additional software fixes for affected products as they
become available," the spokesperson said.

In other words, some patches are available, but others are pending the
investigation.

Espressif Systems: The Chinese vendor has begun patching its chipsets,
namely ESP-IDF and ESP8266 versions, with Arduino ESP32 next on the cards
for a fix.

Fortinet: At the time of writing there was no official advisory, but based
on Fortinet's support forum, it appears that FortiAP 5.6.1 is no longer
vulnerable to most of the CVEs linked to the attack, but the latest branch,
5.4.3, may still be impacted. Firmware updates are expected.

FreeBSD Project: There is no official response at the time of writing.

Google: Google told sister-site CNET that the company is "aware of the
issue, and we will be patching any affected devices in the coming weeks."

HostAP: The Linux driver provider has issued several patches in response to
the disclosure.

Intel: Intel has released a security advisory listing updated Wi-Fi drives
and patches for affected chipsets, as well as Intel Active Management
Technology, which is used by system manufacturers.

Linux: As noted on Charged, a patch is a patch is already available and
Debian builds can patch now, while OpenBSD was fixed back in July.

Netgear: Netgear has released fixes for some router hardware. The full list
can be found here.

Microsoft: While Windows machines are generally considered safe, the
Redmond giant isn't taking any chances and has released a security fix
available through automatic updates.

MikroTik: The vendor has already released patches that fix the
vulnerabilities.

OpenBSD: Patches are now available. (The bastards allowed a diff to be
performed by the bad guys!)

Ubiquiti Networks: A new firmware release, version 3.9.3.7537, protects
users against the attack.

Wi-Fi Alliance: The group is offering a tool to detect KRACK for members
and requires testing for the bug for new members.

Wi-Fi Standard: A fix is available for vendors but not directly for end
users.

At the time of writing, neither Toshiba and Samsung responded to our
requests for comment. If that changes, we will update the story.

[Roger Blake]

On 2017-10-16, harry newton <ha...@is.invalid> wrote:
> This nonce KRACK vulnerability is in *everything*, including smart phones
> (iOS & Android) and computers (Mac/Windows/Linux) and routers
> (Netgear/Cisco/TPLink) ....

Yet there are still people who think the "Internet of Things" is a good idea.

Huge numbers of cheap wifi-connected devices, many poorly-designed, most of
them likely never receiving security updates. What could possibly go wrong?

[harry newton]

He who is Roger Blake said on Tue, 17 Oct 2017 01:03:46 -0000 (UTC):

> Huge numbers of cheap wifi-connected devices, many poorly-designed, most of
> them likely never receiving security updates. What could possibly go wrong?

Well, much more information is out today than yesterday, where it appears
that this situation was handled well since May of this year.

The one open-source fiasco was the anomaly of OpenBSD, which the authors
vowed to never let happen again.

Otherwise, the proprietary solutions were all fixed (or being fixed) in the
way that'd you'd expect.

The problem is in all WiFi WPA1 and WPA2 implementations, but mostly in
Linux and Android "clients" and less so in iOS and Windows clients.

Likewise less so in "routers" not set up as "bridges" (where,
unfortunately, almost all the many routers in my home are almost all set up
as bridges or as stations - all of which are vulnerable).

I guess, when the smoke clears, the problem will be the unsupported
devices, of which Android may be a significant set as may be some of the
older routers and access points.

[J.O. Aho]

On 10/16/17 23:53, harry newton wrote:
> He who is J.O. Aho said on Mon, 16 Oct 2017 21:08:48 +0200:
>
>> They do use a tool commonly used in man-in-the-middle attacks, to strip
>> away the tls and send the content to the client machine unencrypted. As
>> they did explain in the video, many don't check in their mobile devices
>> that they have tls communication or not and those they will be able to
>> carry out the attack to see the the login credentials in this example.
>>
>> This has nothing to do with KRACK itself.
>
> Thanks for explaining *how* they manage to unencrypt *some* encrypted web
> sites but not others, as I wasn't sure how they did that.

You can think of it like

[client]----->[MITM HTTP-service]--->[MITM client]--->[HTTPS Site]

or if you want to keep encryption

[client]----->[MITM HTTPS-service]--->[MITM client]--->[HTTPS Site]

In the first case the client connect to the Man-in-the-middle (MITM)
over http, MITM then resends the data over HTTPS to the site the client
tried to connect to.

In the second example the MITM do allow the client to connect with
HTTPS, the certificate which the MITM has will not be the same as on the
site, so if the client don't verify the certificate, then the attack works.

If you want to read more in detail and better explained how MITM works,
please take a look at:
https://www.owasp.org/index.php/Man-in-the-middle_attack

> I was wrong in assuming it was the KRACK attack, which seems to be that
> they simply hijack the third of the four handshakes, usually from the
> client side, and force it to be resent where in some cases, it's resent as
> all zeroes where in other cases it's just resent as a known nonce.
>
> Is that a decent summary or can you summarize the attack mode better?

I wouldn't say it's hijacked, as you can resend the third request
without knowing the first request. The request is sent to the client and
on the client side, if you have followed the specification and cleared
out the key already, then a zero-key used.
I think they did explain this well on the video.

--

//Aho

[J.O. Aho]

On 10/16/17 23:31, Roger Blake wrote:
> On 2017-10-16, J.O. Aho <us...@example.net> wrote:
>> It's more important to update the client than the server.
>
> Is this something that MS can push an update out for to fix, or does the
> wifi chip vendor need to fix device firmware or device driver?
>

No, not the chip vendor, the manufacturer of the device, for example to
get a fix for your phone, the phone manufacturer has to push out a fix,
then your phone operator may have a custom firmware for your phone, then
you may be vulnerable a lot longer.
When it comes to your wifi, the Access point is usually not a client, so
it's not as vulnerable to the issue. It's important to get updates to
your devices that connects to wifi.

[William Unruh]

On 2017-10-17, J.O. Aho <us...@example.net> wrote:
> On 10/16/17 23:31, Roger Blake wrote:
>> On 2017-10-16, J.O. Aho <us...@example.net> wrote:
>>> It's more important to update the client than the server.
>>
>> Is this something that MS can push an update out for to fix, or does the
>> wifi chip vendor need to fix device firmware or device driver?
>>
>
> No, not the chip vendor, the manufacturer of the device, for example to
> get a fix for your phone, the phone manufacturer has to push out a fix,
> then your phone operator may have a custom firmware for your phone, then
> you may be vulnerable a lot longer.

As I understand it on Android, it uses wpa_supplicant to make the WPA2
connection, and what is needed is to push an updated wpa_supplicant
onto the phone (and presumably something similar for IOS).
I do not think it has anything to do with the firmware.

[David_B]

Thanks, Harry.

Have you read/watched here?
http://www.techrepublic.com/article/krack-wpa2-protocol-wi-fi-attack-how-it-works-and-whos-at-risk/

--
David B.

[harry newton]

He who is David_B said on Tue, 17 Oct 2017 09:04:31 +0100:

> Have you read/watched here?
> http://www.techrepublic.com/article/krack-wpa2-protocol-wi-fi-attack-how-it-works-and-whos-at-risk/

Nice find.
<http://www.techrepublic.com/article/krack-wpa2-protocol-wi-fi-attack-how-it-works-and-whos-at-risk/>
KRACK WPA2 protocol Wi-Fi attack: How it works and who's at risk

Salient points:
. There are 10 CVE identifiers
. All WPA is likely affected especially Android 6.0+ & Linux/MacOS clients
. <https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4>
. Lynchpin is the 4-way handshake to join a WPA network
. wpa_supplicant is the Wi-Fi library that handles the 4-way handshake
. The SSID passphrase is verified & an encryption key is negotiated
. The client waits for the access point to acknowledge the encryption key
. The client will receive the encryption key multiple times in that case
. The client is expected to reinstall that rebroadcast encryption key
. The client is expected to reset the incremental packet transit nonce
. The result is a blank (all zero) encryption key

[Mr. Man-wai Chang]

On 17/10/2017 1:05 AM, harry newton wrote:
> It's more than just routers, so it's *big* - but bear in mind a. Fixes
> will be out soon
> b. Nothing is known in the wild yet
> c. You have to be nearby to be vulnerable

So are these "fixes" really fixing the problem, or are they merely
moving the trap-doors to somewhere? That is, the trap-doors or maybe
"portals" are always opened. :)

[pf...@aol.com]

On Tuesday, October 17, 2017 at 8:11:36 AM UTC-4, Mr. Man-wai Chang wrote:

>
> So are these "fixes" really fixing the problem, or are they merely
> moving the trap-doors to somewhere? That is, the trap-doors or maybe
> "portals" are always opened. :)

Logical fallacy - you cannot know what you do not know.

[harry newton]

He who is Mr. Man-wai Chang said on Tue, 17 Oct 2017 20:11:31 +0800:

> So are these "fixes" really fixing the problem, or are they merely
> moving the trap-doors to somewhere? That is, the trap-doors or maybe
> "portals" are always opened. :)

The author of the KRACK attack pleonasm says that he would expect other
protocols to be similarly afflicted.

[J.O. Aho]

On 10/17/17 07:25, William Unruh wrote:
> On 2017-10-17, J.O. Aho <us...@example.net> wrote:
>> On 10/16/17 23:31, Roger Blake wrote:
>>> On 2017-10-16, J.O. Aho <us...@example.net> wrote:
>>>> It's more important to update the client than the server.
>>>
>>> Is this something that MS can push an update out for to fix, or does the
>>> wifi chip vendor need to fix device firmware or device driver?
>>>
>>
>> No, not the chip vendor, the manufacturer of the device, for example to
>> get a fix for your phone, the phone manufacturer has to push out a fix,
>> then your phone operator may have a custom firmware for your phone, then
>> you may be vulnerable a lot longer.
>
> As I understand it on Android, it uses wpa_supplicant to make the WPA2
> connection, and what is needed is to push an updated wpa_supplicant
> onto the phone (and presumably something similar for IOS).
> I do not think it has anything to do with the firmware.

The wps_supplicant ain't delivered as APK, so you will need a firmware
update. On most GNU/Linux phones it's a package (rpm/deb), so that could
be pushed out without a firmware update.

[William Unruh]

I am pretty sure it is not firmware, but it is part of the Android
package, if that is what you mean. Ie, it is a system program/daemon.
How to replace it I have no idea, esp since it is probably altered by
either Google or by the phone manufacturer. So you are probably right
that it requires them to ship a replacement.

[s|b]

On Mon, 16 Oct 2017 20:55:25 +0200, s|b wrote:

> Still waiting for an update for my TP-Link Archer C7 router. If I
> understand all this correctly, then I'll also need an update for my
> Nexus 5X?

TP-Link is waking up, so it seems:

[Security Flaws] Severe flaws called "KRACK" are discovered in the WPA2
protocol
<http://forum.tp-link.com/showthread.php?101094-Security-Flaws-Severe-flaws-called-quot-KRACK-quot-are-discovered-in-the-WPA2-protocol>

Microsoft announces they patched the leak(s) on October 10.

Microsoft releases statement on KRACK Wi-Fi vulnerability
<https://www.windowscentral.com/microsoft-releases-statement-krack-wi-fi-vulnerability>

--
s|b

[harry newton]

He who is s|b said on Tue, 17 Oct 2017 22:36:45 +0200:

> Microsoft releases statement on KRACK Wi-Fi vulnerability
> <https://www.windowscentral.com/microsoft-releases-statement-krack-wi-fi-vulnerability>

What's interesting is that the open-source community has a problem with
diffs letting the cat out of the bag too soon (witness openbsd).

[William Unruh]

And the closed source community has a problem with never actually fixing
the problems (see most of the wireless router manufacturers).

As can be seen from the debate that occured re Krack and OpenBSD.
Theodore felt that leaving his users hanging completely exposed was not
a good idea, and eventually the Krack finder agreed (only to regret it
later). It is a real moral connundrum. Did anyone actually notice that
OpenBSD could be used to reveal the bug? Ofttimes fear makes one think
that everyone in the world can see right through you and see what you
are trying to hide, while actually noone does.
So it was not a problem, but a true moral connundrum where no answer is
right.

[bruce2...@gmail.com]

Bill Bradshaw wrote:
> It appears if you do not use or have WiFi and enabled you should be

> secure from this. Since I have both disabled I assume I am safe because I
> use neither.

Is a hard wired connection safer (at all distances)?

[harry newton]

He who is William Unruh said on Wed, 18 Oct 2017 02:25:28 -0000 (UTC):

> And the closed source community has a problem with never actually fixing
> the problems (see most of the wireless router manufacturers).

Hi William,
I'm not sure what you mean, but I guess what you're saying is that firmware
is only available for the newest routers, which I would agree with. Is that
what you're saying?

> As can be seen from the debate that occured re Krack and OpenBSD.
> Theodore felt that leaving his users hanging completely exposed was not
> a good idea, and eventually the Krack finder agreed (only to regret it
> later).

Thanks William for understanding what I was talking about. I do see the
conundrum, which is the following, put bluntly:
1. Researcher finds vulnerability on day 0 & secretly informs vendors
2. Proprietary-code vendors fix & release code & nobody is the wiser
3. Open-source vendors fix & release code & anyone can do a "diff"

The problem is that the bad guys can do the diff and then get a jump in the
wild on building an attack vector.

I don't know *how* to solve this, and I don't understand what the Krack
Attack researcher proposed for what Theordore should have done.

> It is a real moral connundrum. Did anyone actually notice that
> OpenBSD could be used to reveal the bug?

William,
Can you help me understand what the researcher prefers for next time?

He used the words "sit on a diff", which I took to mean that someone *knew*
what the changes were and had to "sit on it" (and not tell anyone). (Yes,
I'm well aware of what a "diff" is in the Bash world anyway, which is just
a command revealing what's different.)

I'm confused about one of two events, as to what the researcher wanted:
1. Did he want Theordore to just *sit* on the fix & wait?
2. Or did he propose not giving Theordore enough info to fix it next time?

> Ofttimes fear makes one think
> that everyone in the world can see right through you and see what you
> are trying to hide, while actually noone does.
> So it was not a problem, but a true moral connundrum where no answer is
> right.

But what is the *standard* approach in this situation for open-source code?
What did the researcher propose for open-source code vendors?
1. Did he propose that they not release the code until it's public?
2. Or did he propose not *telling* the open-source community early?

I'm confused what the suggested "solution" by the researcher was.

[Marek Novotny]

The standard approach is to give a short waiting period in which
the researcher who discovers the bug sits on the bug. Meaning that
the researcher does not announce to the world the existence of the
found bug. Instead the researcher notifies vendors and publishers,
such as a distribution or a vendor for a router such as NetGear.

The idea is that they have 60 days in which to patch before the news
goes fully public. The idea here is that sometimes they need to be
shamed publicly for not patching their hardware or software.

In those 60 days all vendors and users of affected software have time
to perform a standard update which should fix the discovered issue
before the issue is revealed after the 60 days.

With open source software since development is out in the open it
is possible to discover the bug before 60 days are up. Development
is in the open after all. Sometimes if it is a really bad one many
distros might agree to release on the same day.

And then you have smaller distros based on larger distros that may lag.
rhel is typically incredibly fast to fix any known issue. Sometimes
in just an hour of it being discovered depending on what it is.

In my opinion this is where Open Source really shines. Something
like a pFsense firewall will get updates very quickly and you can
bank on it. A good distribution like RHEL, Fedora, Debian, Ubuntu,
and Suse will get updates on any particular bug very quickly.

--
Marek Novotny
https://github.com/marek-novotny

[Doomsdrzej]

I have to disagree with the first statement. The open-source community
does fix bugs which are very well-known and widespread. That is why
Krack already has a fix. It's the smaller issues, like graphical
glitches that only affect about 25% of their users which they might
not actually fix. They only prioritize whatever they know they can't
get away without fixing.

[William Unruh]

On 2017-10-18, harry newton <ha...@is.invalid> wrote:

> He who is William Unruh said on Wed, 18 Oct 2017 02:25:28 -0000 (UTC):
>
>> And the closed source community has a problem with never actually fixing
>> the problems (see most of the wireless router manufacturers).
>
> Hi William,
> I'm not sure what you mean, but I guess what you're saying is that firmware
> is only available for the newest routers, which I would agree with. Is that
> what you're saying?

No. Many closed source vendors do not bother trying to fix things unless
their feet are really roasted. In the case of routers, since the primary
attack vector is to clients, and since routers rarely act as clients
(most are not in bridge mode) they do not bother. And other closed
source vendors do not bother since fixing it only affects the bottom
line negatively.

>
>> As can be seen from the debate that occured re Krack and OpenBSD.
>> Theodore felt that leaving his users hanging completely exposed was not
>> a good idea, and eventually the Krack finder agreed (only to regret it
>> later).
>
> Thanks William for understanding what I was talking about. I do see the
> conundrum, which is the following, put bluntly:
> 1. Researcher finds vulnerability on day 0 & secretly informs vendors
> 2. Proprietary-code vendors fix & release code & nobody is the wiser
> 3. Open-source vendors fix & release code & anyone can do a "diff"
>
> The problem is that the bad guys can do the diff and then get a jump in the
> wild on building an attack vector.

The problem is less than you would expect since it requires that the bad
guys actually do the diff. I doubt that there are many who take each
update or kernel/programs, diff them and try to figure out whether it
was a security update they could use, or some other update that which is
of no use to them. Ie, Unless the code or the press point direct fingers
at it, they have no particular reason to zero in on the changes.

>
> I don't know *how* to solve this, and I don't understand what the Krack
> Attack researcher proposed for what Theordore should have done.

Their position now seems to be that Theodore should have waited until
Oct 16 when they announced it, and immediately rolled out the fixes on
that date (as for example Debian did).

>
>> It is a real moral connundrum. Did anyone actually notice that
>> OpenBSD could be used to reveal the bug?
>
> William,
> Can you help me understand what the researcher prefers for next time?
>
> He used the words "sit on a diff", which I took to mean that someone *knew*
> what the changes were and had to "sit on it" (and not tell anyone). (Yes,
> I'm well aware of what a "diff" is in the Bash world anyway, which is just
> a command revealing what's different.)

Make the fix, but do not release it until the embargo is over.

>
> I'm confused about one of two events, as to what the researcher wanted:
> 1. Did he want Theordore to just *sit* on the fix & wait?

He wanted him to sit on the fix until the bug was announced and everyone
could release the fix at the same time.

Note that Theo asked him for permission to release the fix arguing that
it was important for his users not to open to attack. But he asked
permssion. That permission was given, but regretted.

> 2. Or did he propose not giving Theordore enough info to fix it next time?

No, "all" vendors were notified of the problem in August. So everyone
had the opportunity to fix it. The request was to hold off on the
implimentation until a certain date so everyone could fix it at the same
time without warning the bad guys beforehand.

>
>> Ofttimes fear makes one think
>> that everyone in the world can see right through you and see what you
>> are trying to hide, while actually noone does.
>> So it was not a problem, but a true moral connundrum where no answer is
>> right.
>
> But what is the *standard* approach in this situation for open-source code?
> What did the researcher propose for open-source code vendors?
> 1. Did he propose that they not release the code until it's public?
> 2. Or did he propose not *telling* the open-source community early?
>
> I'm confused what the suggested "solution" by the researcher was.

See above.

[William Unruh]

On 2017-10-18, Doomsdrzej <> wrote:
> On Wed, 18 Oct 2017 02:25:28 -0000 (UTC), William Unruh
><un...@invalid.ca> wrote:
>
>>On 2017-10-17, harry newton <ha...@is.invalid> wrote:
>>> He who is s|b said on Tue, 17 Oct 2017 22:36:45 +0200:
>>>
>>>> Microsoft releases statement on KRACK Wi-Fi vulnerability
>>>> <https://www.windowscentral.com/microsoft-releases-statement-krack-wi-fi-vulnerability>
>>>
>>> What's interesting is that the open-source community has a problem with
>>> diffs letting the cat out of the bag too soon (witness openbsd).
>>
>>And the closed source community has a problem with never actually fixing
>>the problems (see most of the wireless router manufacturers).
>>
>>As can be seen from the debate that occured re Krack and OpenBSD.
>>Theodore felt that leaving his users hanging completely exposed was not
>>a good idea, and eventually the Krack finder agreed (only to regret it
>>later). It is a real moral connundrum. Did anyone actually notice that
>>OpenBSD could be used to reveal the bug? Ofttimes fear makes one think
>>that everyone in the world can see right through you and see what you
>>are trying to hide, while actually noone does.
>>So it was not a problem, but a true moral connundrum where no answer is
>>right.
>
> I have to disagree with the first statement. The open-source community
> does fix bugs which are very well-known and widespread. That is why

Note that the fix for Krack was not a fix in the distributions, but a
fix to wpa_supplicant, an external program. So the key person who
should be notified was the developer of wpa_supplicant.
Note that the "zero password" problem, probably the worst of the lot,
could have been fixed privately as if it were a minor improvement (eg
instead of zeroing the password, it could have been filled with random
chaacters and released without inciting much suspicion. Of course making
sure that users actually upgraded would have been a challenge without
the urgency of it being a major flaw that could be attacked.

> Krack already has a fix. It's the smaller issues, like graphical
> glitches that only affect about 25% of their users which they might
> not actually fix. They only prioritize whatever they know they can't
> get away without fixing.

Who are you talking about here? There is a big difference between a bug
which only annoys and a bug which is a security issue.

[Roger Blake]

On 2017-10-18, William Unruh <un...@invalid.ca> wrote:
> No. Many closed source vendors do not bother trying to fix things unless
> their feet are really roasted. In the case of routers, since the primary
> attack vector is to clients, and since routers rarely act as clients
> (most are not in bridge mode) they do not bother. And other closed
> source vendors do not bother since fixing it only affects the bottom
> line negatively.

In some cases it may be possible to run alternative firmware, such
as dd-wrt or tomato, once the appropriate versions for your router
have been patched.

[harry newton]

He who is William Unruh said on Wed, 18 Oct 2017 18:25:42 -0000 (UTC):

> The problem is less than you would expect since it requires that the bad
> guys actually do the diff. I doubt that there are many who take each
> update or kernel/programs, diff them and try to figure out whether it
> was a security update they could use, or some other update that which is
> of no use to them. Ie, Unless the code or the press point direct fingers
> at it, they have no particular reason to zero in on the changes.

Thanks William (and Marek), for explaining what the problem is, but what
did the researcher propose as the *solution* for open-source code?

Did he propose that OpenBSD *wait* until the announcement 50 days later?
How is the researcher going to *enforce* that 50-day waiting period?

>> I don't know *how* to solve this, and I don't understand what the Krack
>> Attack researcher proposed for what Theordore should have done.
>
> Their position now seems to be that Theodore should have waited until
> Oct 16 when they announced it, and immediately rolled out the fixes on
> that date (as for example Debian did).

I see you answered my fundamental confusion (see below).

1. Researcher finds bug on day 0 & plans to announce it 50 days later.
2. OpenSource community has to *wait* until the announcement to ship fixes.
3. Closed-source community can ship when? (any time or wait the 50 days?)

If that's the rules, it seems like it's going to be difficult to *enforce*.

>> He used the words "sit on a diff",

> Make the fix, but do not release it until the embargo is over.

Thank you for confirming he wanted OpenBSD to sit and wait before releasing
the code. I was worried that some *other* researcher ran a diff and had to
"sit on his discovery of that diff" which would have revealed to the
seconde researcher what the flaw in wpa_supplicant was.

What you're telling me is that nobody did that manual third-party "diff" of
the source code so it wasn't revealed in the wild to a third party to our
knowledge before the 50-day waiting period was up.

(Note Marek said 60 days but I think the researchers mentioned only 50 days
but let's not quibble if either one of us is wrong as it's close enough.)

>> I'm confused about one of two events, as to what the researcher wanted:
>> 1. Did he want Theordore to just *sit* on the fix & wait?
>
> He wanted him to sit on the fix until the bug was announced and everyone
> could release the fix at the same time.

That would mean *every* open-source vendor would have to "sit on the fix"
until the announcement. That's fine if the researcher can enforce that.

I guess that is what the standard *should* be but who decides such things?

> Note that Theo asked him for permission to release the fix arguing that
> it was important for his users not to open to attack. But he asked
> permssion. That permission was given, but regretted.

Ah. THANK YOU FOR EXPLAINING. I *knew* there was regret, but to me, a
"diff" is something a third party does of the open-source code to figure
out what's different. The guy who wrote the code doesn't have to run a
"diff" because he *knows* what he wrote.

So I thought a third party who accidentally found out about the bug by
doing a "diff" on the open-source code had to "sit" on it. But that didn't
make sense given the rest of the conversation.

So THANK YOU for explaining that:
A. Researcher finds bug on day 0 & gives all vendors 50 days to fix.
B. OpenBSD fixes it early and asks for permission to ship the code.
C. Researcher provides permission but then regrets that decision.

In the future, I guess, researcher wishes to deny *permission* of
open-source code to ship the fix early, which is a moral conundrum indeed.

And how does the researcher *enforce* this denial of permission to ship
open-source code?

>> 2. Or did he propose not giving Theordore enough info to fix it next time?
>
> No, "all" vendors were notified of the problem in August. So everyone
> had the opportunity to fix it. The request was to hold off on the
> implimentation until a certain date so everyone could fix it at the same
> time without warning the bad guys beforehand.

I see the moral conundrum which pits the visibility of open-source code
against the obfuscation of proprietary code for the case of a knowledgeable
bad guy...

I. In open-source code, a bad guy can do a *diff* to see what changed.
II. If something interesting changed, a bad guy can take advantage of it.
III. In effect, they get to have their own personal 0-day vulnerability.

For the price of a "diff", the bad guy gets his own 0-day vulnerability.
It's a moral conundrum I had never even thought about until today.

[harry newton]

He who is William Unruh said on Wed, 18 Oct 2017 18:41:25 -0000 (UTC):

> Note that the fix for Krack was not a fix in the distributions, but a
> fix to wpa_supplicant, an external program. So the key person who
> should be notified was the developer of wpa_supplicant.

Thanks William (although I know you're responding to someone else) for
bringing up a second moral conundrum, which is how many people to tell.

Since we all know that a secret is no longer a secret if everyone knows
about it, do they normally enforce secrecy rules among *all* developers of
code?

I can imagine, for example, that the Chinese government has at least one
programmer in their employ at *every* software company in the USA (as just
one example), where that programmer is a sleeper (which is trivial for them
to do so I can't believe they don't do it so I assume that they do).

The moral question that arises is:
Do you tell that sleeper if he is NOT the developer of "wpa_supplicant"?

> Note that the "zero password" problem, probably the worst of the lot,
> could have been fixed privately as if it were a minor improvement (eg
> instead of zeroing the password, it could have been filled with random
> chaacters and released without inciting much suspicion. Of course making
> sure that users actually upgraded would have been a challenge without
> the urgency of it being a major flaw that could be attacked.

If we couple the fact that the bad guys (e.g., the Russian mafia, the
Communist sleepers, the NSA/CIA/FBI/GCHQ, etc.,) have an immense bankroll
with the fact that a 'diff' is so obvious to run on open-source code, I
don't know what the *standard* solution is when it gets down to details.

William and Marek already said that the researcher wanted OpenBSD to sit on
the release of the fix until the vulnerability was announced, which opens
up "fork" issues (which may be minor though).

Worse - it opens up the "sleeper" issue depending on what the "need to
know" classified level of who gets to know about the bug before it's
released.

Does everyone sign an NDA before they're told about the bug?
Who enforces when/if that NDA is broken?

[Richard Kettlewell]

harry newton <ha...@is.invalid> writes:
> I see you answered my fundamental confusion (see below).
>
> 1. Researcher finds bug on day 0 & plans to announce it 50 days later.
> 2. OpenSource community has to *wait* until the announcement to ship fixes.
> 3. Closed-source community can ship when? (any time or wait the 50 days?)
>
> If that's the rules, it seems like it's going to be difficult to *enforce*.

Policies like this can be maintained by requiring recipients of
vulnerability predisclosures to agree to maintain confidentiality prior
to embargo dates. An organization could choose to break that agreement,
but they shouldn’t expect to be trusted with predisclosures in the
future if they do so.

> I see the moral conundrum which pits the visibility of open-source code
> against the obfuscation of proprietary code for the case of a knowledgeable
> bad guy...
>
> I. In open-source code, a bad guy can do a *diff* to see what changed.
> II. If something interesting changed, a bad guy can take advantage of it.
> III. In effect, they get to have their own personal 0-day vulnerability.

You can inspect object code to discover what the bugs were, too. A
high-profile example was the 2015 analysis of the Juniper RNG
vulnerability, where no source code was required.

--
https://www.greenend.org.uk/rjk/

[William Unruh]

On 2017-10-18, harry newton <ha...@is.invalid> wrote:

> He who is William Unruh said on Wed, 18 Oct 2017 18:25:42 -0000 (UTC):
>
>> The problem is less than you would expect since it requires that the bad
>> guys actually do the diff. I doubt that there are many who take each
>> update or kernel/programs, diff them and try to figure out whether it
>> was a security update they could use, or some other update that which is
>> of no use to them. Ie, Unless the code or the press point direct fingers
>> at it, they have no particular reason to zero in on the changes.
>
> Thanks William (and Marek), for explaining what the problem is, but what
> did the researcher propose as the *solution* for open-source code?
>
> Did he propose that OpenBSD *wait* until the announcement 50 days later?
> How is the researcher going to *enforce* that 50-day waiting period?

Yes, wait.
Enforcement is a non-issue. He cannot force compliance. He can however
let it be known what they did which will then cause others not to tell
OpenBSD anything when the next problem arises. The people doing open
source distros are responsible people and their intention is not to make
it easy for the bad guys to do nasty things.

>
>>> I don't know *how* to solve this, and I don't understand what the Krack
>>> Attack researcher proposed for what Theordore should have done.
>>
>> Their position now seems to be that Theodore should have waited until
>> Oct 16 when they announced it, and immediately rolled out the fixes on
>> that date (as for example Debian did).
>
> I see you answered my fundamental confusion (see below).
>
> 1. Researcher finds bug on day 0 & plans to announce it 50 days later.
> 2. OpenSource community has to *wait* until the announcement to ship fixes.
> 3. Closed-source community can ship when? (any time or wait the 50 days?)
>
> If that's the rules, it seems like it's going to be difficult to *enforce*.
>
>>> He used the words "sit on a diff",
>> Make the fix, but do not release it until the embargo is over.
>
> Thank you for confirming he wanted OpenBSD to sit and wait before releasing

And that made Theo uncomfortable, so he asked permission to ship early.
He did not simply go ahead and do it.

> the code. I was worried that some *other* researcher ran a diff and had to
> "sit on his discovery of that diff" which would have revealed to the
> seconde researcher what the flaw in wpa_supplicant was.
>
> What you're telling me is that nobody did that manual third-party "diff" of
> the source code so it wasn't revealed in the wild to a third party to our
> knowledge before the 50-day waiting period was up.

WE will never know for sure of course. But there was apparently no
evidence that this crack was actuallyused in the wild. Of course NSA may
have discovered it 5 years ago, or perhaps ISIS did.

>
> (Note Marek said 60 days but I think the researchers mentioned only 50 days
> but let's not quibble if either one of us is wrong as it's close enough.)
>
>>> I'm confused about one of two events, as to what the researcher wanted:
>>> 1. Did he want Theordore to just *sit* on the fix & wait?
>>
>> He wanted him to sit on the fix until the bug was announced and everyone
>> could release the fix at the same time.
>
> That would mean *every* open-source vendor would have to "sit on the fix"
> until the announcement. That's fine if the researcher can enforce that.

What is your hang up about "enforce"?

>
> I guess that is what the standard *should* be but who decides such things?

AGain you are hung up on a "enforce"/central authority thing. People can
behave well all on their own, without legal sanctions or centralized
laws.

>
>> Note that Theo asked him for permission to release the fix arguing that
>> it was important for his users not to open to attack. But he asked
>> permssion. That permission was given, but regretted.
>
> Ah. THANK YOU FOR EXPLAINING. I *knew* there was regret, but to me, a
> "diff" is something a third party does of the open-source code to figure
> out what's different. The guy who wrote the code doesn't have to run a
> "diff" because he *knows* what he wrote.

The permission was to release a patch for the problem. The bad guys
could than run a diff on the released new code to see what was changed.
That is where the diff comes in.

>
> So I thought a third party who accidentally found out about the bug by
> doing a "diff" on the open-source code had to "sit" on it. But that didn't
> make sense given the rest of the conversation.

The worry was that by releasing a patched system, it made it easier for
some bad guy to discover there was a problem and what it was.

>
> So THANK YOU for explaining that:
> A. Researcher finds bug on day 0 & gives all vendors 50 days to fix.
> B. OpenBSD fixes it early and asks for permission to ship the code.
> C. Researcher provides permission but then regrets that decision.
>
> In the future, I guess, researcher wishes to deny *permission* of
> open-source code to ship the fix early, which is a moral conundrum indeed.
>
> And how does the researcher *enforce* this denial of permission to ship
> open-source code?

And again. Note that thousands of security holes have been found and
annnouncent embargoed in the past. So there is a history of the open
source community acting responsibly.

>
>>> 2. Or did he propose not giving Theordore enough info to fix it next time?
>>
>> No, "all" vendors were notified of the problem in August. So everyone
>> had the opportunity to fix it. The request was to hold off on the
>> implimentation until a certain date so everyone could fix it at the same
>> time without warning the bad guys beforehand.
>
> I see the moral conundrum which pits the visibility of open-source code
> against the obfuscation of proprietary code for the case of a knowledgeable
> bad guy...
>
> I. In open-source code, a bad guy can do a *diff* to see what changed.
> II. If something interesting changed, a bad guy can take advantage of it.
> III. In effect, they get to have their own personal 0-day vulnerability.
>
> For the price of a "diff", the bad guy gets his own 0-day vulnerability.
> It's a moral conundrum I had never even thought about until today.

Yes, but many many others have thought about it.

[Snit]

On 10/18/17, 9:38 AM, in article bp0fucp267mmuhhk8...@4ax.com,

They are slow to fix usability issues, but faster to fix security issues.

--
Personal attacks from those who troll show their own insecurity. They cannot
use reason to show the message to be wrong so they try to feel somehow
superior by attacking the messenger.

They cling to their attacks and ignore the message time and time again.

<https://youtu.be/H4NW-Cqh308>

[harry newton]

He who is William Unruh said on Thu, 19 Oct 2017 01:09:07 -0000 (UTC):

>> For the price of a "diff", the bad guy gets his own 0-day vulnerability.
>> It's a moral conundrum I had never even thought about until today.
>
> Yes, but many many others have thought about it.

Thanks for explaining the situation, and the process.

[harry newton]

Does anyone know what *version* of wpa_supplicant contains the KRACK fix?
<http://wetakepic.com/images/2017/10/20/wpa_supplicant.jpg>

LINUX:
x@x:~$ which wpa_supplicant
/sbin/wpa_supplicant
x@x:~$ !$ -version
wpa_supplicant -version
wpa_supplicant v2.4
Copyright (c) 2003-2015, Jouni Malinen <j...@w1.fi> and contributors

WINDOWS:
c:\> wpa_supplicant
'wpa_supplicant' is not recognized as an internal or external command,
operable program or batch file.

[William Unruh]

On 2017-10-20, harry newton <ha...@is.invalid> wrote:
> Does anyone know what *version* of wpa_supplicant contains the KRACK fix?
> <http://wetakepic.com/images/2017/10/20/wpa_supplicant.jpg>

None. It is at present a bunch of patches. However, most distributions
have pushed out a fixed version by now. On Mangeia it is 2.6-1.1 on
Mageia 6, 2.6-1 on Mageia 5 and 2.6-3 on Mageai Cauldron.
You do not tell us which Linux you are refering to.
Note that 2.4 probably does not have the fix.
But it all depends on your distro.

>
> LINUX:
> x@x:~$ which wpa_supplicant
> /sbin/wpa_supplicant
> x@x:~$ !$ -version
> wpa_supplicant -version
> wpa_supplicant v2.4
> Copyright (c) 2003-2015, Jouni Malinen <j...@w1.fi> and contributors
>
> WINDOWS:
> c:\> wpa_supplicant
> 'wpa_supplicant' is not recognized as an internal or external command,
> operable program or batch file.

Windows does not use wpa_supplicant. That is an open source wpa program.
It is used by Android, but again it is probably not a "stock" version,
but may well have been altered by the phone manufacturer to include
special features of the wireless chipset they use.

[harry newton]

He who is William Unruh said on Sat, 21 Oct 2017 00:57:13 -0000 (UTC):

> You do not tell us which Linux you are refering to.
> Note that 2.4 probably does not have the fix.
> But it all depends on your distro.

Thanks William for that detailed technical answer.

I apologize for not providing complete information.
<http://wetakepic.com/images/2017/10/21/ubuntu_version.jpg>

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial
$ cat /etc/*release | grep VERSION
VERSION="16.04.2 LTS (Xenial Xerus)"

> Windows does not use wpa_supplicant. That is an open source wpa program.
> It is used by Android, but again it is probably not a "stock" version,
> but may well have been altered by the phone manufacturer to include
> special features of the wireless chipset they use.

Thanks William. It's so refreshing to deal with actual technical answers!

Here is what my Android 4.3 phone just reported:
<http://wetakepic.com/images/2017/10/21/android_wpa.jpg>

$ wpa_supplication -version
wpa_supplicant v2.1-d15el-4.3 2015-08-13/21:13:54
Copyright (c) 2003-2014, Jouni Malinen <j...@wl.fi> and contributors

[William Unruh]

On 2017-10-21, harry newton <ha...@is.invalid> wrote:
> He who is William Unruh said on Sat, 21 Oct 2017 00:57:13 -0000 (UTC):
>
>> You do not tell us which Linux you are refering to.
>> Note that 2.4 probably does not have the fix.
>> But it all depends on your distro.
>
> Thanks William for that detailed technical answer.
>
> I apologize for not providing complete information.
><http://wetakepic.com/images/2017/10/21/ubuntu_version.jpg>

Debian (on which Ubuntu is based) came out with those patches on Monday
I think. Ie, the version on the Ubuntu sight by Wed was probably the
patched version. If yours was installed befor Wed it almost certainly is
not patched. Definitely if it was before Mon the 16th it is not patched.

>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.2 LTS
> Release: 16.04
> Codename: xenial
> $ cat /etc/*release | grep VERSION
> VERSION="16.04.2 LTS (Xenial Xerus)"
>
>> Windows does not use wpa_supplicant. That is an open source wpa program.
>> It is used by Android, but again it is probably not a "stock" version,
>> but may well have been altered by the phone manufacturer to include
>> special features of the wireless chipset they use.
>
> Thanks William. It's so refreshing to deal with actual technical answers!
>
> Here is what my Android 4.3 phone just reported:
><http://wetakepic.com/images/2017/10/21/android_wpa.jpg>

It really says nothing. They could have patched that version of 2.1 Or
probably not. Although there is a claim in the original that it was
wpa_supplicant 2.4 and later that were problematic. And that it is
android 6 and later that is problematic. I have no idea whether that is
because those are the only ones tested, or because earlier ones are OK.

[Richard Kettlewell]

harry newton <ha...@is.invalid> writes:
> He who is William Unruh said on Sat, 21 Oct 2017 00:57:13 -0000 (UTC):
>> You do not tell us which Linux you are refering to. Note that 2.4
>> probably does not have the fix.
>> But it all depends on your distro.
>
> Thanks William for that detailed technical answer.
>
> I apologize for not providing complete information.
> <http://wetakepic.com/images/2017/10/21/ubuntu_version.jpg>
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.2 LTS
> Release: 16.04
> Codename: xenial
> $ cat /etc/*release | grep VERSION
> VERSION="16.04.2 LTS (Xenial Xerus)"

You need 2.4-0ubuntu6.2.
http://changelogs.ubuntu.com/changelogs/pool/main/w/wpa/wpa_2.4-0ubuntu6.2/changelog

Use dpkg -l to check the package version.

--
https://www.greenend.org.uk/rjk/

[Jonathan N. Little]

Richard Kettlewell wrote:
> dpkg -l

Or apt-cache:

~$ apt-cache policy wpasupplicant
wpasupplicant:
Installed: 2.4-0ubuntu6.2
Candidate: 2.4-0ubuntu6.2
Version table:
*** 2.4-0ubuntu6.2 500
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main
amd64 Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main
amd64 Packages
100 /var/lib/dpkg/status
2.4-0ubuntu6 500
500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

Also latest version of 16.04 is:

$ lsb_release -d
Description: Ubuntu 16.04.3 LTS

sudo apt-get update && sudo apt-get dist-upgrade

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Brian Gregory]

On 16/10/2017 13:46, harry newton wrote:
> Did you update your router for the WPA2/PSK KRACK nonce re-use attack yet?
> <https://www.krackattacks.com>
>
> I reported it yesterday over here with links...
> <https://groups.google.com/forum/#!forum/alt.internet.wireless>
>
> They made it public a half hour ago:
> <https://groups.google.com/d/msg/alt.internet.wireless/vn8yRnm7UF8/N89Wcd_OAAAJ>
>
>
> Manufacturers apparently had 50 days to effect the fix:
> Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2
> <https://papers.mathyvanhoef.com/ccs2017.pdf>
>

Patches at the access point end are relatively unimportant.

What you need to patch most are your client devices.

--

Brian Gregory (in the UK).
To email me please remove all the letter vee from my email address.

[Andy Burns]

Brian Gregory wrote:

> Patches at the access point end are relatively unimportant.

LEDE 17.01.4 includes the KRACK fixes, no point not upgrading.

> What you need to patch most are your client devices.

True, but it includes an optional AP-side workaround for devices that
haven't been (may never be?) patched ...

<https://lede-project.org/docs/user-guide/wifi_configuration#wpa_key_reinstallation_attack_workaround>

[harry newton]

How does this colloquial summary for my family look - in case you want to
send one to YOUR family?
========
People are asking what to do about the KRACK Attack vulnerability (note the
pleonasm), so I figured I'd let everyone know what it is & I figured I'd
give folks the opportunity to ask question if they're concerned.

The canonical site for the attack is written by the white hat who found it:
<https://www.krackattacks.com/>

Here's my ad-hoc summary, written with respect to what you and I need to
know & do.

1. In May, the white hat notified the government & vendors he found a bug
in all WPA WiFi (e.g., WPA2) where someone who is *close* enough to
intercept the signals can see everything you do.

2. It affects all WiFi but the worst affected is Android at or over version
6, macOS, Linux, and really fast (i.e., 802.11r fast roaming) routers set
up as repeaters (i.e., as a second router).

Far less affected are iPhones, WiFi iPads, WiFi iPods, older Android
devices, Windows computers, and normal routers (e.g., 802.11n or 802.11ac),
especially if they're set up as the main router (and not as a repeater).

3. There is only one viable solution, which is to *update* your device
firmware or software, whether that be a mobile phone, a laptop, a desktop,
a router working as a repeater, or the main router.

The order of priority should be:
a. If you have Android 6+, then you *should* update soon.
b. If you have MacOS or Linux, then you should update soon.
c. If you have an 802.11r router, then you should update soon.

You can take your sweet time on everything else, but everything needs to be
updated.

4. The problem, of course, is *how* to update each device.
a. First look for your device to see if there is an update
<https://www.kb.cert.org/vuls/id/228519>
b. Then try to find the update
<http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/>
c. Then update.

What a pain. Let me know if you have questions.
========

[William Unruh]

On 2017-10-29, harry newton <ha...@is.invalid> wrote:
> How does this colloquial summary for my family look - in case you want to
> send one to YOUR family?
>========
> People are asking what to do about the KRACK Attack vulnerability (note the
> pleonasm), so I figured I'd let everyone know what it is & I figured I'd
> give folks the opportunity to ask question if they're concerned.
>
> The canonical site for the attack is written by the white hat who found it:
><https://www.krackattacks.com/>
>
> Here's my ad-hoc summary, written with respect to what you and I need to
> know & do.
>
> 1. In May, the white hat notified the government & vendors he found a bug
> in all WPA WiFi (e.g., WPA2) where someone who is *close* enough to
> intercept the signals can see everything you do.

No, whose interception point is close enough. Thus your wirelessly
connected fridge, which usually has attrocious security, could possibly
be used as an interception point for an attacker who is in Mongolia say.

>
> 2. It affects all WiFi but the worst affected is Android at or over version
> 6, macOS, Linux, and really fast (i.e., 802.11r fast roaming) routers set
> up as repeaters (i.e., as a second router).

All wifi is susceptible, including Windows. The problem with Android and
Linux is they all use wpa_supplicant and it has a problem that, for
security, it zeros the password after using it. But that means that when
the replay occurs it uses that 0 password. Thus fixing wpa_supplicant
fixes the problem, and it has in principle been fixed. Of course one needs
to get that fixed version into the devices.

>
> Far less affected are iPhones, WiFi iPads, WiFi iPods, older Android
> devices, Windows computers, and normal routers (e.g., 802.11n or 802.11ac),
> especially if they're set up as the main router (and not as a repeater).

The problem is a client side problem. But all of those devices are
susceptible to at least some version of Krack, and should not assumed to
be "far less affected". They are all affected. That they do not have the
"zero password" problem is irrelevant since they have other attack
vectors.

>
> 3. There is only one viable solution, which is to *update* your device
> firmware or software, whether that be a mobile phone, a laptop, a desktop,
> a router working as a repeater, or the main router.

Yes, for all of them, not just Linux and Android.

>
> The order of priority should be:
> a. If you have Android 6+, then you *should* update soon.
> b. If you have MacOS or Linux, then you should update soon.
> c. If you have an 802.11r router, then you should update soon.

If you have any wireless device you should update soon. I have no idea
why you are categorizing them.

>
> You can take your sweet time on everything else, but everything needs to be
> updated.

Why in the world would you say you can take your sweet time on them.
They are all vulnerable.

>
> 4. The problem, of course, is *how* to update each device.
> a. First look for your device to see if there is an update
> <https://www.kb.cert.org/vuls/id/228519>
> b. Then try to find the update
> <http://www.zdnet.com/article/here-is-every-patch-for-krack-wi-fi-attack-available-right-now/>
> c. Then update.
>
> What a pain. Let me know if you have questions.

So, 4 is the only thing you really need to say. Of course how you are
going to update your fridge or your toaster is a bit obscure. Do you
really want a "owned" wifi device anywhere on your internal network?

[harry newton]

He who is William Unruh said on Sun, 29 Oct 2017 14:47:35 -0000 (UTC):

> No, whose interception point is close enough. Thus your wirelessly
> connected fridge, which usually has attrocious security, could possibly
> be used as an interception point for an attacker who is in Mongolia say.

Interesting point. Thank you for that observation.

I think what you're saying is that if they can get to *any* of your
devices, over the Internet, then, *from those devices*, they can intercept
your traffic to, for example, your Linux laptop or Android smart phone.

But I'm confused about the risk in that case.

Are they only intercepting from the refrigerator-to-the-client-device?
Or are they then able to get from your router-to-your-client-device?

(The latter would be more dangerous.)

> All wifi is susceptible, including Windows. The problem with Android and
> Linux is they all use wpa_supplicant and it has a problem that, for
> security, it zeros the password after using it. But that means that when
> the replay occurs it uses that 0 password. Thus fixing wpa_supplicant
> fixes the problem, and it has in principle been fixed. Of course one needs
> to get that fixed version into the devices.

Here is a writeup I made for my family that others can use which shows just
*one* example of fixing a WiFI device. In this case, it's a Ubiquti radio
set up as an access point and only going about a half kilometer, but it
could be set up to go for miles (as some of my other radios are set up).

(0) Log into your radio
<http://wetakepic.com/images/2017/10/29/00_PB400_firmware_update_krack.jpg>

(1) Check the firmware version (noting the board revision, e.g., XW)
<http://wetakepic.com/images/2017/10/29/01_PB400_firmware_update_krack.jpg>

(2) Hit the "Check Now" button to see if you can update from here
<http://wetakepic.com/images/2017/10/29/02_PB400_firmware_update_krack.jpg>

(3) If not, go to the manufacturer's web site to locate the firmware file
<http://wetakepic.com/images/2017/10/29/03_PB400_firmware_update_krack.jpg>

(4) You may have to agree to the manufacturer's updated EULA
<http://wetakepic.com/images/2017/10/29/04_PB400_firmware_update_krack.jpg>

(5) Download the file to a known location on your computer
<http://wetakepic.com/images/2017/10/29/05_PB400_firmware_update_krack.jpg>

(6) Save the file in a logical location on your computer for future use
<http://wetakepic.com/images/2017/10/29/06_PB400_firmware_update_krack.jpg>

(7) Then in the radio, press the "Upload Firmware Choose File" button
<http://wetakepic.com/images/2017/10/29/07_PB400_firmware_update_krack.jpg>

(8) Wait for the firmware to upload (it may take a minute or two)
<http://wetakepic.com/images/2017/10/29/08_PB400_firmware_update_krack.jpg>

(9) Once uploaded, press the "Update" button to update the firmware
<http://wetakepic.com/images/2017/10/29/09_PB400_firmware_update_krack.jpg>

(10) Wait for the firmware to be updated (it may take a minute or two)
<http://wetakepic.com/images/2017/10/29/10_PB400_firmware_update_krack.jpg>

(11) Do not power down while you are waiting for the firmware to update
<http://wetakepic.com/images/2017/10/29/11_PB400_firmware_update_krack.jpg>

(12) When done, the radio will reboot; log back in to check results
<http://wetakepic.com/images/2017/10/29/12_PB400_firmware_update_krack.jpg>

(13) You should note that the firmware should now be updated
<http://wetakepic.com/images/2017/10/29/13_PB400_firmware_update_krack.jpg>

(14) Doublecheck now that everything is updated that it is working fine
<http://wetakepic.com/images/2017/10/29/14_PB400_firmware_update_krack.jpg>

> So, 4 is the only thing you really need to say. Of course how you are
> going to update your fridge or your toaster is a bit obscure. Do you
> really want a "owned" wifi device anywhere on your internal network?

I have over a dozen WiFi devices in my house.... so I'm updating them one
by one. I'm more worried about my grandchildren not knowing how to update
*their* devices, and my older siblings, etc.

But I agree, it's a PITA to update *every* WiFi device in the house.
I have over a half-dozen access point radios, for example, and a few on the
roof, etc., some of which connect by WiFi to homes that are 10 miles away,
so it's a pain for any of them.

[Andy Burns]

harry newton wrote:

> I think what you're saying is that if they can get to *any* of your
> devices, over the Internet, then, *from those devices*, they can intercept
> your traffic to, for example, your Linux laptop or Android smart phone.

I think in your case you say your house is out of wifi range of your
neighbours; but since you're advising friends and family, it could be
that one house's fridge/camera/thermostat hacks the neighbour's wifi
traffic ...

[harry newton]

He who is Andy Burns said on Sun, 29 Oct 2017 16:53:03 +0000:

I understand only the *basics* of that argument, which is that if you have
device 0 (the router), and then client 1 (refrigerator) and client 2
(Android phone), and client 3 (linux laptop) that *all* are vulnerable.

The basic argument is that if someone gets in on client 1, 2, or 3, then
the *whole* network is compromised.

But is it?

If client 1 is a refrigerator with very poor security, I get it that they
can hack easily into client 1.

All I'm asking is how does access to client 1 give them access to router 0
which "controls" the entire LAN?

[William Unruh]

On 2017-10-29, harry newton <ha...@is.invalid> wrote:

It doesn't directly. But they now have control of a wireless card, which they
can adapt (software) to listen in on the traffic between your computer and the
router (remember that the wireless signal goes everywhere), and can then
subvert the communication between the computer and the router forcing the
system into negotiation replay. I have no desire to figure out exactly how to
do that, just that with fridges etc around with zero security, they have an in
to your local network, and quite possibly can use that to run a Krack on the
computer and the router.