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