4 ms·

Or as Juli Mallett put it on Twitter, "If you can deal with FreeBSD -CURRENT crashing, you can deal with the RNG being b0rked for a few months." This is indeed

by emaste 12y ago

Or as Juli Mallett put it on Twitter, "If you can deal with FreeBSD -CURRENT crashing, you can deal with the RNG being b0rked for a few months." This is indeed a serious issue, and I'm disappointed it was in the source tree for four months. But -CURRENT is the development branch, and is not supported by the FreeBSD security team, or supported for use in production. From https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html#CURRENT https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/c...: FreeBSD-CURRENT is made available for three primary interest groups: Members of the FreeBSD community who are actively working on some part of the source tree. Members of the FreeBSD community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of FreeBSD, and submitting patches. Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution. FreeBSD-CURRENT should not be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. FreeBSD-CURRENT is not in any way “officially supported”.

mikeash 12y ago
This bug is much, much worse than a crash. I can understand the sentiment that you should be prepared for even horrible bugs like this if you're running -CURRENT, but "if you can deal with crashing, you can deal with this" is completely wrong. Instability is a completely different beast from potentially generating easily crackable crypto keys.
- barkingcat 12y ago
  In my opinion, it's much much better that this was corrected! If there were to be any bug of any kind, -CURRENT is the best place in freebsd to have it. I'm not sure what you're trying to argue for/against unless you are looking at things from a pure number theory/computer science research point of view? What would people do then? Create perfect flawless code that never malfunctions even as they write it? Code that never has bugs does not exist. Perfect algorithms don't exist either. -CURRENT is exactly the place for this because RNG bugs exist in reality. If you read emaste's post above, this bug "potentially generates easily crackable crypto keys" for the safe to a monopoly game that holds monopoly money. It's a development kernel.
  - mikeash 12y ago
    The only thing I'm arguing here is that dealing with crashes does not imply you can deal with severe crypto compromises. In short, that the above-quoted tweet is completely bogus. That's all.
    - coldtea 12y ago
      How are "severe crypto compromises" any worse than crashes and potential data corruption and business interruption?
      - detaro 12y ago
        A crashing test environment is no real danger, a compromised test environment could be the source of a lot of trouble (stealing code deployed to it, ...). Of course, it shouldn't be exposed enough to be successfully attacked in the first place...
      - nitrogen 12y ago
        Any ssh key generated with a bad RNG could be easily crackable, as an example.
      - mikeash 12y ago
        Because it poisons data produced on that machine in an invisible way. Normally you could use a system like this on a trial basis and keep the results. For example, you might run some image processing on it. You'd want to make sure the output was good, but having done so you could then use those images for real-world tasks without worry. But replace "image processing" with "generate a private key" and now you're deeply screwed. Well, now we know. Don't generate crypto keys on pre-release OSes that you're going to use for anything important. That's reasonable. But I don't think many people would have thought that way before. And of course pre-release OSes aren't the only place the danger lies. Debian had a similar problem that made it to releases and stayed undetected for a couple of years. The point is just that "silently break all your crypto" is a much worse vulnerability than mere crashes, or even corruption.
- emaste 12y ago
  I agree that this is much worse than a crash if you care about your keys, and I'm not trying to suggest otherwise. My point is that -CURRENT may be rather unstable at any given time, and is explicitly not supported. One should not be using it a production deployment where sensitive key material may exist.
  - drostie 12y ago
    There's a point that's even more germane: if you take the money and dev time that would be required to build an exploit to hose your system, you could probably for a comparable sum pay your programmers to obfuscate a new zero-day vulnerability into the FreeBSD kernel on the premise that it's an experimental feature. In that regard the 'crashability' of the branch is indeed more significant than a random-numbers exploit: the crashability of the branch is a mnemonic for its general permissiveness towards unaudited (or not-sufficiently-audited) code. When you remember that your adversaries can inject code into the OS, that changes your threat modeling.
    - tedunangst 12y ago
      Huh? "This crashes, therefore I bet it has backdoors." Does anybody really think like that? What happens when the crashes get fixed and the not crashing backdoor turns into -release?
      - drostie 12y ago
        It makes sense if you look at it as a correlation, not as causation. The point is that one cause (less review of experimental kernel features), which is known to underlie the "this crashes" problem, can also potentially cause the "it could have back-doors" problem. Of course, as you say, not-crashing back-doors can make it into releases, too. Open source's generic promise that more eyes will make bugs shallow is not a guarantee.

by emaste 12y ago

mikeash 12y ago

This bug is much, much worse than a crash. I can understand the sentiment that you should be prepared for even horrible bugs like this if you're running -CURRENT, but "if you can deal with crashing, you can deal with this" is completely wrong. Instability is a completely different beast from potentially generating easily crackable crypto keys.

barkingcat 12y ago
In my opinion, it's much much better that this was corrected! If there were to be any bug of any kind, -CURRENT is the best place in freebsd to have it. I'm not sure what you're trying to argue for/against unless you are looking at things from a pure number theory/computer science research point of view? What would people do then? Create perfect flawless code that never malfunctions even as they write it? Code that never has bugs does not exist. Perfect algorithms don't exist either. -CURRENT is exactly the place for this because RNG bugs exist in reality. If you read emaste's post above, this bug "potentially generates easily crackable crypto keys" for the safe to a monopoly game that holds monopoly money. It's a development kernel.
- mikeash 12y ago
  The only thing I'm arguing here is that dealing with crashes does not imply you can deal with severe crypto compromises. In short, that the above-quoted tweet is completely bogus. That's all.
  - coldtea 12y ago
    How are "severe crypto compromises" any worse than crashes and potential data corruption and business interruption?
    - detaro 12y ago
      A crashing test environment is no real danger, a compromised test environment could be the source of a lot of trouble (stealing code deployed to it, ...). Of course, it shouldn't be exposed enough to be successfully attacked in the first place...
    - nitrogen 12y ago
      Any ssh key generated with a bad RNG could be easily crackable, as an example.
    - mikeash 12y ago
      Because it poisons data produced on that machine in an invisible way. Normally you could use a system like this on a trial basis and keep the results. For example, you might run some image processing on it. You'd want to make sure the output was good, but having done so you could then use those images for real-world tasks without worry. But replace "image processing" with "generate a private key" and now you're deeply screwed. Well, now we know. Don't generate crypto keys on pre-release OSes that you're going to use for anything important. That's reasonable. But I don't think many people would have thought that way before. And of course pre-release OSes aren't the only place the danger lies. Debian had a similar problem that made it to releases and stayed undetected for a couple of years. The point is just that "silently break all your crypto" is a much worse vulnerability than mere crashes, or even corruption.
emaste 12y ago
I agree that this is much worse than a crash if you care about your keys, and I'm not trying to suggest otherwise. My point is that -CURRENT may be rather unstable at any given time, and is explicitly not supported. One should not be using it a production deployment where sensitive key material may exist.
- drostie 12y ago
  There's a point that's even more germane: if you take the money and dev time that would be required to build an exploit to hose your system, you could probably for a comparable sum pay your programmers to obfuscate a new zero-day vulnerability into the FreeBSD kernel on the premise that it's an experimental feature. In that regard the 'crashability' of the branch is indeed more significant than a random-numbers exploit: the crashability of the branch is a mnemonic for its general permissiveness towards unaudited (or not-sufficiently-audited) code. When you remember that your adversaries can inject code into the OS, that changes your threat modeling.
  - tedunangst 12y ago
    Huh? "This crashes, therefore I bet it has backdoors." Does anybody really think like that? What happens when the crashes get fixed and the not crashing backdoor turns into -release?
    - drostie 12y ago
      It makes sense if you look at it as a correlation, not as causation. The point is that one cause (less review of experimental kernel features), which is known to underlie the "this crashes" problem, can also potentially cause the "it could have back-doors" problem. Of course, as you say, not-crashing back-doors can make it into releases, too. Open source's generic promise that more eyes will make bugs shallow is not a guarantee.