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

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.

--
@~@ 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_...sub_addressesa

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.

On Tue, 17 Oct 2017 12:30:04 +0000 (UTC), harry newton
wrote:

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.

I am sure people that do nothing but look for problems can find
something wrong with every piece of equipment/software. Of course when
it becomes common knowledge, it causes more harm than good. ALMOST
every person on earth wants some kind of notoriety.


KenW

On 10/17/17 07:25, William Unruh wrote:
On 2017-10-17, J.O. Aho wrote:
On 10/16/17 23:31, Roger Blake wrote:
On 2017-10-16, J.O. Aho 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.

On 2017-10-17, J.O. Aho wrote:
On 10/17/17 07:25, William Unruh wrote:
On 2017-10-17, J.O. Aho wrote:
On 10/16/17 23:31, Roger Blake wrote:
On 2017-10-16, J.O. Aho 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.

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.

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

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

On 2017-10-17, harry newton 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.

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.

On 2017-10-18, harry newton 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?

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.

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

On Wed, 18 Oct 2017 02:25:28 -0000 (UTC), William Unruh
wrote:

On 2017-10-17, harry newton 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
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.

On 2017-10-18, harry newton 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.

On 2017-10-18, Doomsdrzej wrote:
On Wed, 18 Oct 2017 02:25:28 -0000 (UTC), William Unruh
wrote:

On 2017-10-17, harry newton 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.

On 2017-10-18, William Unruh 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.

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

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.