View Single Post
  #41   Report Post  
Posted to alt.comp.os.windows-10,alt.os.linux,sci.electronics.repair
William Unruh William Unruh is offline
external usenet poster
 
Posts: 16
Default Did you update your router for the WPA2/PSK KRACK nonce re-useattack yet?

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.