by Anonymous Coward writes:
on Monday January 08, 2018 @07:46AM (#55884257)
I disagree. Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes. There are lots of operating systems that run on the 32 and 64 bit AMD/Intel architecture. Should every single OS developer be notified of the vulnerability? Alternatively, notify those who have the largest user base, while trying to limit the disclosure. There is no perfect solution, but I favor limited disclosure. Frankly, OpenBSD just isn't that widely used, and if there were more users, they probably would have been notified ahead of the public disclosure.
Yes, Intel has tried to conflate Spectre and Meltdown to avoid negative PR. That is a legitimate criticism, but one that's not at all new. Otherwise, it's a lot of butthurt because OpenBSD just doesn't have that many users, and therefore wasn't notified.
Also it might be possible that he was intentionally left out due to trust issues after patching the Krack attack and thus disclosing info about it prematurely.
That doesn't explain why FreeBSD wasn't notified until 5-6 months after Intel and ARM knew about the issue and until after Apple had shipped a patch. It also wasn't helped that there was no real coordination in releases. Apple shipped a binary update and there were patches in the Linux tree containing mitigation before the official end of the embargo period.
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans. Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either. Google's Project Zero team presumably had discussions with Intel and select others they felt they could trust about what was required to address the problem and how long it would take, and that group collectively agreed on the original release date of January 9th, plus who else to notify and when. Clearly that larger group did not include anyone in the BSD camp.
Standing up for your principles can have a cost attached, and I suspect we've just seen what that was for Theo and the BSD developers.
Yes, I do realise that - but it doesn't change the situation that *all* the BSD devs were kept out of the loop regardless of which family they work on. If you consider that there is still a lot of overlap between the two teams in terms of the code and contributors, then it would be kind of hard for FreeBSD to be making changes and testing them - especially if they wanted to roll them out publically like Linux did - without at least some of the OpenBSD devs either being in the loop or figuring out that some
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans.
When has FreeBSD ever disclosed a security vulnerability under embargo? FreeBSD has a security officer and a secteam group that are the only ones that have access to any embargoed security information and have separate infrastructure from the rest of the project for preparing fixes. Only people who have signed the relevant NDAs are allowed access to anything shared with this group and they are normally given information about embargoed security issues as a result.
Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either
You do realise that FreeBSD and OpenBSD are entirely different projects, run by different people, with different infrastructure and different codebases and that Theo De Raadt has no connection to the FreeBSD project?
It also wasn't helped that there was no real coordination in releases.
There was, the problem is exactly what they were trying to avoid. It was under non-disclosure back in November. The actual full disclosure date wasn't supposed to be until tomorrow (9th Jan) so coordinated releases could take place. Unfortunately someone jumped the gun and we're left with the clusterfuck that this has become (Microsoft patches released, Apple patches released, UEFI patches not ready yet, Linux patches scheduled for original date).
This one of the very few downsides of Opensource. It's diffic
Because it's FreeBSD. They're not a real player and they can be butthurt, but gosh darn it I rolled my own experimental kernel and I sure wasn't notified either.
Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.
We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
Read the answer again, the author allowed the OpenBSD developers to silently patch the vulnerability... and then blames them because someone discovered it.
With a vulnerability disclosure of that scale, I can forgive a researcher for making a poor decision. Maybe you spend months to years bug hunting and make one discovery.
But someone who deals with a near constant stream of high severity bugs, should take a more considered position.
Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes.
This has a very poor underlying assumption: White hats always know about exploits prior to Black hats. Considering the latter are far better funded, have better incentives, and don't disclose; I think the betting is that it is already used for malicious purposes.
Additionally, this is the information age, not the dead tree, secret squirrel, stamped "for your eyes only" days. In this age, does it really matter if 100 or 10000 people know a confidential piece of information? You only need ONE individual in
That’s what I was wondering too. Seems too easy for it to leak, whilst most everyone who is actually affected is kept in the dark.
My takeaway message, for me, is that, any secret key or whatever, on a machine which ran newly downloaded and possibly untrusted code, now needs recreating on a fresh system. And it would have been nice to have known that months ago, even if no fix was available.
This is like the old days where the doctor doesn’t inform you of terminal illness, because they think they
"The C Programming Language -- A language which combines the flexibility of
assembly language with the power of assembly language."
Disagree (Score:0, Interesting)
I disagree. Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes. There are lots of operating systems that run on the 32 and 64 bit AMD/Intel architecture. Should every single OS developer be notified of the vulnerability? Alternatively, notify those who have the largest user base, while trying to limit the disclosure. There is no perfect solution, but I favor limited disclosure. Frankly, OpenBSD just isn't that widely used, and if there were more users, they probably would have been notified ahead of the public disclosure.
Yes, Intel has tried to conflate Spectre and Meltdown to avoid negative PR. That is a legitimate criticism, but one that's not at all new. Otherwise, it's a lot of butthurt because OpenBSD just doesn't have that many users, and therefore wasn't notified.
Re:Disagree (Score:4, Interesting)
Re:Disagree (Score:5, Insightful)
Re:Disagree (Score:4, Insightful)
Standing up for your principles can have a cost attached, and I suspect we've just seen what that was for Theo and the BSD developers.
Re:Disagree (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
You do realise that OpenBSD and FreeBSD are two different entities, right?
You do realise there's more in common between them than what sets them apart, including a lot of sharing between developers.
Re:Disagree (Score:5, Informative)
Sure it does. If you want to keep something quiet until you are ready to announce it, then you DO NOT tell any of the people who have a track record of spilling the beans.
When has FreeBSD ever disclosed a security vulnerability under embargo? FreeBSD has a security officer and a secteam group that are the only ones that have access to any embargoed security information and have separate infrastructure from the rest of the project for preparing fixes. Only people who have signed the relevant NDAs are allowed access to anything shared with this group and they are normally given information about embargoed security issues as a result.
Regardless of where you personally stand on the idea of embargos and standing up for principles, Theo refused to go along with an embargo previously and it was quite likely that he wouldn't do so this time either
You do realise that FreeBSD and OpenBSD are entirely different projects, run by different people, with different infrastructure and different codebases and that Theo De Raadt has no connection to the FreeBSD project?
Because Intel neglected *BSD... (Score:2)
...I would not be surprised to see advocacy for alternative architectures from those circles, be that AMD or ARM.
Theo can now rightly say that Intel design flaws will have 0-day impacts on OpenBSD that are beyond his control.
Re: (Score:3)
It also wasn't helped that there was no real coordination in releases.
There was, the problem is exactly what they were trying to avoid. It was under non-disclosure back in November. The actual full disclosure date wasn't supposed to be until tomorrow (9th Jan) so coordinated releases could take place. Unfortunately someone jumped the gun and we're left with the clusterfuck that this has become (Microsoft patches released, Apple patches released, UEFI patches not ready yet, Linux patches scheduled for original date).
This one of the very few downsides of Opensource. It's diffic
Re: (Score:2, Troll)
Re: (Score:2)
Yeah, that pissed a lot of people off.
Re: (Score:1)
Should every single OS developer be notified of the vulnerability?
Yes
Next question.
Re: (Score:2)
According to whom?
Re:Disagree (Score:5, Informative)
Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.
We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
Re: (Score:1)
Read the answer again, the author allowed the OpenBSD developers to silently patch the vulnerability... and then blames them because someone discovered it.
Re: (Score:3)
With a vulnerability disclosure of that scale, I can forgive a researcher for making a poor decision. Maybe you spend months to years bug hunting and make one discovery.
But someone who deals with a near constant stream of high severity bugs, should take a more considered position.
Re: (Score:3)
Wider disclosure of a vulnerability means a greater chance that it's leaked to those who would exploit it for malicious purposes.
This has a very poor underlying assumption: White hats always know about exploits prior to Black hats. Considering the latter are far better funded, have better incentives, and don't disclose; I think the betting is that it is already used for malicious purposes.
Additionally, this is the information age, not the dead tree, secret squirrel, stamped "for your eyes only" days. In this age, does it really matter if 100 or 10000 people know a confidential piece of information? You only need ONE individual in
Re: (Score:2)
That’s what I was wondering too. Seems too easy for it to leak, whilst most everyone who is actually affected is kept in the dark.
My takeaway message, for me, is that, any secret key or whatever, on a machine which ran newly downloaded and possibly untrusted code, now needs recreating on a fresh system. And it would have been nice to have known that months ago, even if no fix was available.
This is like the old days where the doctor doesn’t inform you of terminal illness, because they think they