5 ms·

Well, no. It was caught in the CURRENT branch -- i.e. latest-and-greatest snapshots for developers. Users who use this branch are supposed to accept some breaka

• 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.
• tptacek 12y ago
  It's a weird rhetorical position you're putting me in, where to agree with you I'd have to simultaneously accept that -CURRENT isn't widely deployed (reasonable!) and that a broken kernel RNG isn't a game-over flaw (not so reasonable!).
  • drostie 12y ago
    The reason that the latter point is reasonable is, it trivially isn't a game-over flaw for systems which do not have game-overs. What we know about every system that installed FreeBSD-CURRENT is that the systems administrators at the time fully accepted an operating system: 1. That is not in any way "officially supported". (FreeBSD's words, not mine.) 2. that may for short periods of time "not be buildable." 3. that "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". 4. that is much weaker in guarantees than the FreeBSD-STABLE branch, which expressly disclaims, "one should not blindly track FreeBSD-STABLE. It is particularly important not to update any production servers to FreeBSD-STABLE without thoroughly testing the code in a development or testing environment." If someone has signed off on these topics, then there is no such thing as "game over". The server isn't important enough for "game over". If it is, then the security vulnerability was not the broken RNG but tracking FreeBSD-CURRENT in the first place.
    • nitrogen 12y ago
      Suppose a developer generated an ssh key while running -current and shared /home with -stable. Then the vulnerability would long outlast the use of -current.
  • barkingcat 12y ago
    It's not that it's not widely deployed - it's that -CURRENT is deployed by people who have been warned that it could fail at any moment because it is in constant development. It's a development tree, sometimes it doesn't even boot! Sometimes on svn upgrade (and recompile) it can hose your filesystem partitions and that's expected. Forget about the RNG - when someone is working on filesystem code it corrupts files and you lose all your data! I can say this with a straight face because that's what it's for. I say it's a game-ON plan because thank goodness it got caught in -CURRENT now - that's the way the development process is supposed to work. I myself run -CURRENT 2 ways - one is a sandbox development physical box that has no access to any of my other servers (I use it to try ports to see if they will still work on -CURRENT), and the 2nd way is in a VM on my laptop to fire it up to see if it boots from time to time.
• cnst 12y ago
  This is a way to discourage and scare off people from running -CURRENT. That's why FreeBSD releases, in general, are much buggier and have many more regressions than OpenBSD, because on OpenBSD, something like this in -current would be as big of a deal as it making it into a -release, and everyone (not just the developers) is actually encouraged to run -current to make sure any kind of bugs would be caught up in time. BTW, links to the referenced revisions: http://svnweb.freebsd.org/changeset/base/273872 http://svnweb.freebsd.org/changeset/base/273872 http://svnweb.freebsd.org/changeset/base/278907 http://svnweb.freebsd.org/changeset/base/278907
  • barkingcat 12y ago
    In my opinion this is a great thing to expose people to the freebsd development process! It's a big enough deal to get people to understand just what -CURRENT is, and hopefully it makes people want to build it and start fixing bugs!
• tedunangst 12y ago
  > A broken RNG in such circumstances is much, much weaker than kernel RCE. How do you reach this conclusion? If nobody runs -current, then the damage associated with a -current RCE must also be scaled down by a similar factor, no? On the other hand, a -current test system which later gets upgraded to the next release for production will still have busted keys on it, but would have had the RCE fixed.
• javert 12y ago
  This is rationalistic. I guess if my house is burglered because I left the door unlocked, you'd say I'm blameless as long as my "threat model" assumed that any burglers always come in through the window.
  • hhw 12y ago
    A more appropriate house analogy would be getting burgled by someone walking through your not yet existent living room wall of your half constructed house. The security flaw then is not that you're missing a wall, as it's not reasonable to expect walls to be put up instantaneously, but that: a) you left valuables at a construction site or b) you didn't have a fence around the construction site
  • drostie 12y ago
    I mean, yes. What you're trying to point out is that sometimes the real threat model (i.e. the security concerns list of the stakeholders) is not the same as the explicit modeling they do of threats. And that's actually very common: HTTPS, for example, is based on a model of eavesdropping threats which only applies to a small case of real-world security problems (public WiFi), models a lot of threats which haven't been so important (ISP malfeasance, DNS hijacking) and the resulting certificate system may be worse for some bigger matters of network security (protecting from government eavesdropping, for example) when compared to something like SSH. But HTTPS is a good security standard for what it does, and we don't claim that HTTPS sucks just because a lot of people have malware on their PCs which can trivially transmit their traffic to untrusted third parties. Rather, it's your responsibility to revise your explicit threat models to accord with your own implicit expectations. Your clients' students are suddenly upset that your client was storing Social Security Numbers on your servers, which could be read by the public via your API? You have hereby discovered that your "explicit" threat model, which left the front door unlocked, was failing to live up to an "implicit" threat model which you had. You now need to either punt the problem off to the client ("we're not storing your sensitive info, our service is not appropriate for that!") or update your explicit model ("we're re-securing our systems and assuming that everything is potentially sensitive, so new permissions systems will guard access"). Running and continuing to run -CURRENT when you know that occasionally the front door's locks can fall off for any or no reason, means that you've accepted this reality.