30 ms·

It seems that OpenBSD already patched their source code and that wasn't to the likings of the researcher. In the future he will now delay notifying OpenBSD of v

It seems that OpenBSD already patched their source code and that wasn't to the likings of the researcher. In the future he will now delay notifying OpenBSD of vulnerabilities. Why did OpenBSD silently release a patch before the embargo? OpenBSD was notified 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.

0x0 9y ago
Not the first time OpenBSD does not respect embargoes, for example https://lwn.net/Articles/726585/ https://lwn.net/Articles/726585/ and https://lwn.net/Articles/726580/ https://lwn.net/Articles/726580/
- philippnagel 9y ago
  As a user I am completely fine with that.
  - nasduia 9y ago
    Even when the author states that now as a result of that selfishness OpenBSD won't get notified about vulnerabilities until well after everyone else?
    - cjsuk 9y ago
      What about the vulnerabilities that OpenBSD notice? Works both ways. And they have an active interest in such things and have discovered as much as any famous-for-five-minutes security researcher.
      - JumpCrisscross 9y ago
        > [OpenBSD] have discovered as much as any famous-for-five-minutes security researcher TL; DR OpenBSD acted rationally if they'd prefer to go it alone, which seems to be their culture. To their credit, it's worked pretty well so far. But you can't have your cake and eat it too. If they prefer a mad scramble after public disclosure, they'll get it. But they shouldn't get early notice from responsible researchers.
        cjsuk 9y ago
        See my comment here. It sort of replies to this anyway: https://news.ycombinator.com/item?id=15482285 https://news.ycombinator.com/item?id=15482285 I don't believe that embargo is healthy or responsible! If anything its a monopolising factor.
    - temprature 9y ago
      > OpenBSD won't get notified about vulnerabilities until well after everyone else Which doesn't make a difference if OpenBSD still gets their patch out at the same time as everyone else. Unlike other vendors, it doesn't take OpenBSD four months to go from vulnerability notification to patch release, if you look at previous disclosure timelines they typically have a patch out in days.
    - abcdef123xyz 9y ago
      It sounds rather like he is trying to blame OpenBSD for his own mistake. As multiple people from OpenBSD have said, he agreed they could apply the fix, so they did. He didn't have to say they could. The fact that CERT persuaded him to extend the embargo later is not their fault.
- tedunangst 9y ago
  A bunch of dudes on a linux mailing list lack the authority to prevent openbsd from fixing things.
  - Xylakant 9y ago
    True, they don't. However, this researcher has the authority to not notify the openbsd team in advance any more and he already announced that he'll keep his cards closer next time. What happens if sufficient researchers come to the same conclusion?
    - cjsuk 9y ago
      What happens if a vendor or researcher is in bed with the NSA and they use the exploit while embargoed? The whole thing is a shit show and really I'm rather more behind OpenBSD's approach. Edit just to expand on this as someone deleted a post .... ---- It's slightly more complicated than the prisoner's dilemma. The prisoner's dilemma doesn't account for a large facet of the problem which is being discussed here. If all the good parties participate and coordinate then we're better off. The problem is there are outlying circumstances which means that not everyone will be included: 1. If someone kicks someone out (OpenBSD) on political whim playing CYA, they no longer benefit. 2. If a party is not let in, they no longer benefit. 3. If someone is unaware of it, they don't benefit. This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule. The first thing the people outside of the club find is they wake up on Monday morning and have to clear up a shitstorm of monumental proportions with less resources than the monopolised vendors who've had time to deal with it. Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid.
      - deleted 9y ago
        [deleted]
      - tedunangst 9y ago
        Yeah, the hysterical part is how people think distros is leak proof. It just doesn't leak in nice public ways to allow "responsible white hats" to wag their fingers. Raise your hand if you can say you confidently know the full back channel distribution of a notification to distros.
- gizzlon 9y ago
  "As a compromise, I allowed them to silently patch the vulnerability." The way I read that they broke no embargo
  - cyphar 9y ago
    They were pressured by OpenBSD to do so, and regret it. That doesn't mean they broke embargo, but it also doesn't reflect well on them. Do you think Theo would've respected the embargo if they had said "no, do not patch until the embargo date?"
    - brians 9y ago
      Yes. He would have tried to persuade them, perhaps cut out the researchers to persuade CERT.
    - abcdef123xyz 9y ago
      Who says they were pressured?
- JumpCrisscross 9y ago
  Sounds like the researcher is at fault for putting OpenBSD on their list. If you cut a deal with someone who serially defects, at a certain point the onus shifts from them to your lack of foresight.
  - noobermin 9y ago
    The problem isn't a "fool me once shame on...fool me you don't get fooled again", because the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it.
    - JumpCrisscross 9y ago
      > the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it Sure, but eventually you get called out on it in a public forum, like this one, and people stop giving you goodies going forward. I would consider it acceptable practice to, when considering dealing with OpenBSD (or people who are close to them), (a) withhold vulnerabilities until after the embargo date or (b) refuse to give any information unless they sign a binding non-disclosure agreement committing them to the deadline under pain of penalty. (The latter is an option because it appears, in this case, they broke the spirit if not letter of the agreement. The solution to that problem is legalese.)
      - stsp 9y ago
        Hi, I am the person you are accusing of mischief. I didn't break any agreement. I agreed with Mathy on what to do, and that's what I did. The fact that Mathy decided to get CERT involved and subsequently had to extend the embargo has nothing to do with me. (edit: typo)
        JumpCrisscross 9y ago
        To be clear, I accuse you of nothing less than playing a rational response to the researcher's apparent "always coöperate" strategy. "Defect" in a prisoner's dilemma context does not mean "breach" in a legal one. (For example, an OPEC member defecting has zero legal consequences. It does, however, affect their standing in the next round of negotiations.)
iaml 9y ago
The researcher's reaction is correct. OpenBSD maintainers' lack of patience may have led to this vulnerability being discovered and exploited by other people.
- claudius 9y ago
  The researcher’s lack of full disclosure may have lead to this vulnerability being discovered and exploited by other people.
  - Xylakant 9y ago
    As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network. The attack might already be known to hostile actors or may have become known during the embargo, but full disclosure without an embargo would guarantee that clients are at risk without mitigation. An embargo at least gives time to prep patches and protect at least a portion of the clients.
    - claudius 9y ago
      Either there is a possibility for patches to be prepared during an embargo or there is “no client-side mitigation”, you can’t have both. From reading the rest of this thread, it appears that it is quite possible to patch this on clients such that, if you are using a patched client, you are safe. Disclosing earlier would have lead to more people having patched clients earlier and hence being safe.
      - Xylakant 9y ago
        Patching the client is a fix. Mitigation would bea config setting that makes me safer (disable some unused functionality,...). So yes, you can have both.
        claudius 9y ago
        That’s like saying that prior to introducing seatbelts, we should have allowed for a period of time to glue people to their seats because it is preferable to have a mitigation they can apply themselves than a fix the manufacturer has to put in. If you don’t limit mitigation to "a config setting" (and why would you?!), a patch/new version is the best mitigation you can get.
titzer 9y ago
This feels like some kind of prisoner's dilemma game theory problem. By defecting from the embargo, OpenBSD gained potential security for its users at the expense of all other users. Overall, this is a loss, unless you use OpenBSD. I have to agree with the researchers on this one; OpenBSD acted selfishly here.
- tedunangst 9y ago
  Read that again. We asked to commit without revealing details, he said yes, that's what happened. I guess he changed his mind about that after the fact, but nobody promised not to commit. We didn't "defect" from an embargo unilaterally.
  - mtgx 9y ago
    Sounds like a "we technically respected the embargo, just not in principle" sort of thing to me.
    - dom0 9y ago
      They agreed, but now they regret the decision and wouldn't make it again. To prevent themselves from doing so, they will not speak with OpenBSD until later in the process.
      - gcp 9y ago
        What's the word for pressuring a person until they make a decision they immediately regret?
        deleted 9y ago
        [deleted]
    - tedunangst 9y ago
      We're not mind readers. If he says it's ok, we think it's ok. If other vendors have fucked up months long patch cycles, that's their deal, not ours.
akerro 9y ago
Author doesn't know what FreeBSD, Debian and OpenBSD people cooperate and share knowledge, so most probably OpenBSD developers will know about the issues, just not from an "official" email.
- Jach 9y ago
  Furthermore by not even attempting to include OpenBSD in some embargo agreement, there's no reason for OpenBSD to not patch as soon as they hear about it. Indeed that's what seems to have happened on the linked 'evidence' about them not respecting an embargo of a linux distro group they're not part of.
asclepi 9y ago
For reference, the OpenBSD patch in question released on August 30: https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_net80211_replay.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_n...
- acqq 9y ago
  tedunangst: "We asked to commit without revealing details, he said yes" "I guess he changed his mind about that after the fact." The patch has obviously an explicit description: "State transition errors could cause reinstallation of old WPA keys." It's true, however, that anybody who analyzes the diffs would eventually figure that out, as Theo de Raadt argued. My conclusion is also that the real error was even wanting to give the details to him at that moment, as there's apparently a history of him not respecting embargoes.
  - tedunangst 9y ago
    Oh, that's the problem? That's too much information? Well, shit.
    - acqq 9y ago
      I still fail to get what you wanted to express with your comment here. I've just quoted two sentences from another comment of yours on the same page, have you understood something else?
- kodablah 9y ago
  On GitHub, appears at [0] with comments coming in today at [1]. 0 - https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309bce0e05e65eec66648f#diff-3b9c911e172fd99f012c4a3ed8a3b47e https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309b... 1 - https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea60b4d332d744b651c3#diff-3b9c911e172fd99f012c4a3ed8a3b47e https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea...

0x0 9y ago

Not the first time OpenBSD does not respect embargoes, for example https://lwn.net/Articles/726585/ https://lwn.net/Articles/726585/ and https://lwn.net/Articles/726580/ https://lwn.net/Articles/726580/

philippnagel 9y ago
As a user I am completely fine with that.
- nasduia 9y ago
  Even when the author states that now as a result of that selfishness OpenBSD won't get notified about vulnerabilities until well after everyone else?
  - cjsuk 9y ago
    What about the vulnerabilities that OpenBSD notice? Works both ways. And they have an active interest in such things and have discovered as much as any famous-for-five-minutes security researcher.
    - JumpCrisscross 9y ago
      > [OpenBSD] have discovered as much as any famous-for-five-minutes security researcher TL; DR OpenBSD acted rationally if they'd prefer to go it alone, which seems to be their culture. To their credit, it's worked pretty well so far. But you can't have your cake and eat it too. If they prefer a mad scramble after public disclosure, they'll get it. But they shouldn't get early notice from responsible researchers.
      - cjsuk 9y ago
        See my comment here. It sort of replies to this anyway: https://news.ycombinator.com/item?id=15482285 https://news.ycombinator.com/item?id=15482285 I don't believe that embargo is healthy or responsible! If anything its a monopolising factor.
  - temprature 9y ago
    > OpenBSD won't get notified about vulnerabilities until well after everyone else Which doesn't make a difference if OpenBSD still gets their patch out at the same time as everyone else. Unlike other vendors, it doesn't take OpenBSD four months to go from vulnerability notification to patch release, if you look at previous disclosure timelines they typically have a patch out in days.
  - abcdef123xyz 9y ago
    It sounds rather like he is trying to blame OpenBSD for his own mistake. As multiple people from OpenBSD have said, he agreed they could apply the fix, so they did. He didn't have to say they could. The fact that CERT persuaded him to extend the embargo later is not their fault.
tedunangst 9y ago
A bunch of dudes on a linux mailing list lack the authority to prevent openbsd from fixing things.
- Xylakant 9y ago
  True, they don't. However, this researcher has the authority to not notify the openbsd team in advance any more and he already announced that he'll keep his cards closer next time. What happens if sufficient researchers come to the same conclusion?
  - cjsuk 9y ago
    What happens if a vendor or researcher is in bed with the NSA and they use the exploit while embargoed? The whole thing is a shit show and really I'm rather more behind OpenBSD's approach. Edit just to expand on this as someone deleted a post .... ---- It's slightly more complicated than the prisoner's dilemma. The prisoner's dilemma doesn't account for a large facet of the problem which is being discussed here. If all the good parties participate and coordinate then we're better off. The problem is there are outlying circumstances which means that not everyone will be included: 1. If someone kicks someone out (OpenBSD) on political whim playing CYA, they no longer benefit. 2. If a party is not let in, they no longer benefit. 3. If someone is unaware of it, they don't benefit. This turns it into a security monopoly where the big vendors get exclusive rights to embargo and exclude smaller vendors and control the disclosure process on their own schedule. The first thing the people outside of the club find is they wake up on Monday morning and have to clear up a shitstorm of monumental proportions with less resources than the monopolised vendors who've had time to deal with it. Then there's the assumption that the monopolised vendors are trustworthy which is 100% impossible to validate and therefore invalid.
    - deleted 9y ago
      [deleted]
    - tedunangst 9y ago
      Yeah, the hysterical part is how people think distros is leak proof. It just doesn't leak in nice public ways to allow "responsible white hats" to wag their fingers. Raise your hand if you can say you confidently know the full back channel distribution of a notification to distros.
gizzlon 9y ago
"As a compromise, I allowed them to silently patch the vulnerability." The way I read that they broke no embargo
- cyphar 9y ago
  They were pressured by OpenBSD to do so, and regret it. That doesn't mean they broke embargo, but it also doesn't reflect well on them. Do you think Theo would've respected the embargo if they had said "no, do not patch until the embargo date?"
  - brians 9y ago
    Yes. He would have tried to persuade them, perhaps cut out the researchers to persuade CERT.
  - abcdef123xyz 9y ago
    Who says they were pressured?
JumpCrisscross 9y ago
Sounds like the researcher is at fault for putting OpenBSD on their list. If you cut a deal with someone who serially defects, at a certain point the onus shifts from them to your lack of foresight.
- noobermin 9y ago
  The problem isn't a "fool me once shame on...fool me you don't get fooled again", because the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it.
  - JumpCrisscross 9y ago
    > the problem is one unscrupulous party is unscrupulous to different parties and the different parties at different times are unaware of it Sure, but eventually you get called out on it in a public forum, like this one, and people stop giving you goodies going forward. I would consider it acceptable practice to, when considering dealing with OpenBSD (or people who are close to them), (a) withhold vulnerabilities until after the embargo date or (b) refuse to give any information unless they sign a binding non-disclosure agreement committing them to the deadline under pain of penalty. (The latter is an option because it appears, in this case, they broke the spirit if not letter of the agreement. The solution to that problem is legalese.)
    - stsp 9y ago
      Hi, I am the person you are accusing of mischief. I didn't break any agreement. I agreed with Mathy on what to do, and that's what I did. The fact that Mathy decided to get CERT involved and subsequently had to extend the embargo has nothing to do with me. (edit: typo)
      - JumpCrisscross 9y ago
        To be clear, I accuse you of nothing less than playing a rational response to the researcher's apparent "always coöperate" strategy. "Defect" in a prisoner's dilemma context does not mean "breach" in a legal one. (For example, an OPEC member defecting has zero legal consequences. It does, however, affect their standing in the next round of negotiations.)

iaml 9y ago

The researcher's reaction is correct. OpenBSD maintainers' lack of patience may have led to this vulnerability being discovered and exploited by other people.

claudius 9y ago
The researcher’s lack of full disclosure may have lead to this vulnerability being discovered and exploited by other people.
- Xylakant 9y ago
  As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network. The attack might already be known to hostile actors or may have become known during the embargo, but full disclosure without an embargo would guarantee that clients are at risk without mitigation. An embargo at least gives time to prep patches and protect at least a portion of the clients.
  - claudius 9y ago
    Either there is a possibility for patches to be prepared during an embargo or there is “no client-side mitigation”, you can’t have both. From reading the rest of this thread, it appears that it is quite possible to patch this on clients such that, if you are using a patched client, you are safe. Disclosing earlier would have lead to more people having patched clients earlier and hence being safe.
    - Xylakant 9y ago
      Patching the client is a fix. Mitigation would bea config setting that makes me safer (disable some unused functionality,...). So yes, you can have both.
      - claudius 9y ago
        That’s like saying that prior to introducing seatbelts, we should have allowed for a period of time to glue people to their seats because it is preferable to have a mitigation they can apply themselves than a fix the manufacturer has to put in. If you don’t limit mitigation to "a config setting" (and why would you?!), a patch/new version is the best mitigation you can get.

titzer 9y ago

This feels like some kind of prisoner's dilemma game theory problem. By defecting from the embargo, OpenBSD gained potential security for its users at the expense of all other users. Overall, this is a loss, unless you use OpenBSD. I have to agree with the researchers on this one; OpenBSD acted selfishly here.

tedunangst 9y ago
Read that again. We asked to commit without revealing details, he said yes, that's what happened. I guess he changed his mind about that after the fact, but nobody promised not to commit. We didn't "defect" from an embargo unilaterally.
- mtgx 9y ago
  Sounds like a "we technically respected the embargo, just not in principle" sort of thing to me.
  - dom0 9y ago
    They agreed, but now they regret the decision and wouldn't make it again. To prevent themselves from doing so, they will not speak with OpenBSD until later in the process.
    - gcp 9y ago
      What's the word for pressuring a person until they make a decision they immediately regret?
      - deleted 9y ago
        [deleted]
  - tedunangst 9y ago
    We're not mind readers. If he says it's ok, we think it's ok. If other vendors have fucked up months long patch cycles, that's their deal, not ours.

akerro 9y ago

Author doesn't know what FreeBSD, Debian and OpenBSD people cooperate and share knowledge, so most probably OpenBSD developers will know about the issues, just not from an "official" email.

Jach 9y ago
Furthermore by not even attempting to include OpenBSD in some embargo agreement, there's no reason for OpenBSD to not patch as soon as they hear about it. Indeed that's what seems to have happened on the linked 'evidence' about them not respecting an embargo of a linux distro group they're not part of.

asclepi 9y ago

For reference, the OpenBSD patch in question released on August 30: https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_net80211_replay.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_n...

acqq 9y ago
tedunangst: "We asked to commit without revealing details, he said yes" "I guess he changed his mind about that after the fact." The patch has obviously an explicit description: "State transition errors could cause reinstallation of old WPA keys." It's true, however, that anybody who analyzes the diffs would eventually figure that out, as Theo de Raadt argued. My conclusion is also that the real error was even wanting to give the details to him at that moment, as there's apparently a history of him not respecting embargoes.
- tedunangst 9y ago
  Oh, that's the problem? That's too much information? Well, shit.
  - acqq 9y ago
    I still fail to get what you wanted to express with your comment here. I've just quoted two sentences from another comment of yours on the same page, have you understood something else?
kodablah 9y ago
On GitHub, appears at [0] with comments coming in today at [1]. 0 - https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309bce0e05e65eec66648f#diff-3b9c911e172fd99f012c4a3ed8a3b47e https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309b... 1 - https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea60b4d332d744b651c3#diff-3b9c911e172fd99f012c4a3ed8a3b47e https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea...