4 ms·

Is there not some sort of OS embargo consortium that could be created to resolve this?

by fny 9y ago

blibble 9y ago
they previously broke the KRACK embargo (among others): https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh... it's no surprise they're not high up on the list of important people to tell
- blattimwind 9y ago
  No one seems to have told the other BSDs, either.
  - kuschku 9y ago
    FreeBSD was told in December, which is still a realistic timeline.
    - JdeBP 9y ago
      Late December, i.e. a week or so before the cat actually got let out of the bag, and probably around a fortnight's notice until the originally planned coördinated announcement date. * https://news.ycombinator.com/item?id=16074531 https://news.ycombinator.com/item?id=16074531 That is hardly enough time, considering that it is likely a holiday period for most of the people concerned, to prepare what needed to be prepared. Google and Intel gave themselves six months, in contrast, and they gave Ubuntu since November 2017. I still haven't nailed down how much advanced notice Matthew Dillion, author of DragonFly BSD, was given; although his apparent level of preparedness with patches on 2018-01-05 can be attributed to the fact that he actually talked publicly about the problem in April 2017, months before Google Project Zero secretly reported it to processor manufacturers in June 2017 in the first place. * https://news.ycombinator.com/item?id=16084641 https://news.ycombinator.com/item?id=16084641
      - kuschku 9y ago
        > That is hardly enough time, considering that it is likely a holiday period for most of the people concerned, to prepare what needed to be prepared. Google and Intel gave themselves six months, in contrast, and they gave Ubuntu since November 2017. Correct, but it’s significantly better than OpenBSD’s timeline (which learnt about it from the media). Mitigation for Meltdown is possible within of a week, or two. It requires working through the night, but it’s possible. Mitigation after it’s in the media is a whole different situation.
        JdeBP 9y ago
        No, it is not significantly better. Contrasted with the months that the likes of Microsoft, Ubuntu, and (going by what Paolo Bonzini has already said on Hacker News) RedHat got, FreeBSD and OpenBSD were in practical terms in the same boat. The difference of a week, when that week is Christmastide, is insignificant when put alongside those.
- cm2187 9y ago
  And the guy complains in the same paragraph that there are embargoes and that he wasn't in on the embargo... If he doesn't want embargoes he should be happy to discover the vulnerability with everyone else.
- temprature 9y ago
  He told them they could go ahead, he then regretted it but that's not OpenBSD's fault. From https://www.krackattacks.com/#openbsd https://www.krackattacks.com/#openbsd : > As a compromise, I allowed them to silently patch the vulnerability. Receiving permission to patch is the opposite of breaking an embargo.
  - xucheng 9y ago
    And it continues: > 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.
sverige 9y ago
The problem with embargoes is that they tend to run so long that users are put at risk unnecessarily. Most of the reasons for extending embargoes way beyond the time needed to prepare and test patches are just bullshit. For example, from the conversation on the KRACK embargo: >Q. What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about a vulnerability, the shorter an embargo time the better. > A. There’s a couple of different interests at play. > For instance: > Researchers want to make a timed media splash. > Security agencies want to evaluate the problem and make sure they get patched before anyone else. > Vendors want time to prepare patches, yes, but that alone does not justify such a long delay. > Reviewing the patch, testing it, and preparing it for commit and publishing erratas took only a couple of hours of my free time. Apparently Meltdown was discovered back in June, or seven months ago. Only a select few were told about it and have been working on it. It is apparent that some are more equal than others in the "free and open source community," which ironically apparently includes Microsoft, Apple, and the three-letter agencies.
- throwaway2048 9y ago
  yes im sure security agencies spend as long as possible "evaluating the problem"
- xucheng 9y ago
  I think there is another important reason to extend embargoes aside preparing patches. Vulnerabilities like Meltdown and Spectre are in fact a whole new family of attack methods. It would take time to fully evaluate the extent of the problem. I would not be surprised that we learn new variants of Spectre in the coming future.
  - emn13 9y ago
    These classes of attacks are not new. Timing attack in crypto have been widely used for a long time. And even specifically in CPU's there was stuff like http://www.daemonology.net/papers/htt.pdf http://www.daemonology.net/papers/htt.pdf and http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.1003&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190... over ten years ago(!). To quote that last paper: > We show how processor architecture features such as simultaneous multithreading, control speculation and shared caches can inadvertently accelerate such covert channels or enable new covert channels and side channels. We first illustrate the reality and severity of this problem by describing concrete attacks. So not just were side-channel attacks on CPUs documented; specifically the dangers of speculative execution and caching on intel cpus (there: the Itanium) was documented. It's inconceivable that this comes as a surprise to Intel. They're playing the public for fools. Of course some of this is intrinsic: speculative loading, caching, and accurate timers are an intrinsic problem: an JIT running in the same process as the JITted code will not be able to keep secrets from that JITted code while all three are in play. But intel specifically also allowed this across memory protection boundaries, which isn't necessary.

Is there not some sort of OS embargo consortium that could be created to resolve this?

by fny 9y ago

Is there not some sort of OS embargo consortium that could be created to resolve this?

they previously broke the KRACK embargo (among others): https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh... it's no surprise they're not high up on the list of important people to tell

blattimwind 9y ago
No one seems to have told the other BSDs, either.
- kuschku 9y ago
  FreeBSD was told in December, which is still a realistic timeline.
  - JdeBP 9y ago
    Late December, i.e. a week or so before the cat actually got let out of the bag, and probably around a fortnight's notice until the originally planned coördinated announcement date. * https://news.ycombinator.com/item?id=16074531 https://news.ycombinator.com/item?id=16074531 That is hardly enough time, considering that it is likely a holiday period for most of the people concerned, to prepare what needed to be prepared. Google and Intel gave themselves six months, in contrast, and they gave Ubuntu since November 2017. I still haven't nailed down how much advanced notice Matthew Dillion, author of DragonFly BSD, was given; although his apparent level of preparedness with patches on 2018-01-05 can be attributed to the fact that he actually talked publicly about the problem in April 2017, months before Google Project Zero secretly reported it to processor manufacturers in June 2017 in the first place. * https://news.ycombinator.com/item?id=16084641 https://news.ycombinator.com/item?id=16084641
    - kuschku 9y ago
      > That is hardly enough time, considering that it is likely a holiday period for most of the people concerned, to prepare what needed to be prepared. Google and Intel gave themselves six months, in contrast, and they gave Ubuntu since November 2017. Correct, but it’s significantly better than OpenBSD’s timeline (which learnt about it from the media). Mitigation for Meltdown is possible within of a week, or two. It requires working through the night, but it’s possible. Mitigation after it’s in the media is a whole different situation.
      - JdeBP 9y ago
        No, it is not significantly better. Contrasted with the months that the likes of Microsoft, Ubuntu, and (going by what Paolo Bonzini has already said on Hacker News) RedHat got, FreeBSD and OpenBSD were in practical terms in the same boat. The difference of a week, when that week is Christmastide, is insignificant when put alongside those.
cm2187 9y ago
And the guy complains in the same paragraph that there are embargoes and that he wasn't in on the embargo... If he doesn't want embargoes he should be happy to discover the vulnerability with everyone else.
temprature 9y ago
He told them they could go ahead, he then regretted it but that's not OpenBSD's fault. From https://www.krackattacks.com/#openbsd https://www.krackattacks.com/#openbsd : > As a compromise, I allowed them to silently patch the vulnerability. Receiving permission to patch is the opposite of breaking an embargo.
- xucheng 9y ago
  And it continues: > 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.

sverige 9y ago

The problem with embargoes is that they tend to run so long that users are put at risk unnecessarily. Most of the reasons for extending embargoes way beyond the time needed to prepare and test patches are just bullshit. For example, from the conversation on the KRACK embargo: >Q. What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about a vulnerability, the shorter an embargo time the better. > A. There’s a couple of different interests at play. > For instance: > Researchers want to make a timed media splash. > Security agencies want to evaluate the problem and make sure they get patched before anyone else. > Vendors want time to prepare patches, yes, but that alone does not justify such a long delay. > Reviewing the patch, testing it, and preparing it for commit and publishing erratas took only a couple of hours of my free time. Apparently Meltdown was discovered back in June, or seven months ago. Only a select few were told about it and have been working on it. It is apparent that some are more equal than others in the "free and open source community," which ironically apparently includes Microsoft, Apple, and the three-letter agencies.

throwaway2048 9y ago
yes im sure security agencies spend as long as possible "evaluating the problem"
xucheng 9y ago
I think there is another important reason to extend embargoes aside preparing patches. Vulnerabilities like Meltdown and Spectre are in fact a whole new family of attack methods. It would take time to fully evaluate the extent of the problem. I would not be surprised that we learn new variants of Spectre in the coming future.
- emn13 9y ago
  These classes of attacks are not new. Timing attack in crypto have been widely used for a long time. And even specifically in CPU's there was stuff like http://www.daemonology.net/papers/htt.pdf http://www.daemonology.net/papers/htt.pdf and http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.1003&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190... over ten years ago(!). To quote that last paper: > We show how processor architecture features such as simultaneous multithreading, control speculation and shared caches can inadvertently accelerate such covert channels or enable new covert channels and side channels. We first illustrate the reality and severity of this problem by describing concrete attacks. So not just were side-channel attacks on CPUs documented; specifically the dangers of speculative execution and caching on intel cpus (there: the Itanium) was documented. It's inconceivable that this comes as a surprise to Intel. They're playing the public for fools. Of course some of this is intrinsic: speculative loading, caching, and accurate timers are an intrinsic problem: an JIT running in the same process as the JITted code will not be able to keep secrets from that JITted code while all three are in play. But intel specifically also allowed this across memory protection boundaries, which isn't necessary.