Slashdot Mirror


The Fedora-Red Hat Crisis

jammag writes "When Linux journalist Bruce Byfield tried to dig for details about the security breach in Fedora's servers, a Red Hat publicist told him the official statement — written in non-informative corporate-speak — was all he would get. In the wake of Red Hat's tight-lipped handling of the breach, even Fedora's board was unhappy, as Byfield details. He concludes: 'If Red Hat, one of the epitomes of a successful FOSS-based business, can ignore FOSS when to do so is corporately convenient, then what chance do we have that other companies — especially publicly-traded ones — will act any better?'"

7 of 263 comments (clear)

  1. Re:Press Releases... by FlyingBishop · · Score: 4, Informative
    No, you can't...

    This goes back to the whole "trusting trust" concept. You have no way of knowing if the source you've been given reflects the binary you're using, unless you yourself compiled it (and hand-crafted the compiler you're using in assembly, and made the assembly language for your CPU, and made your CPU, but those are a different discussion.)

    The point is, Red Hat signs their packages. If their signing mechanism has been compromised, it is quite conceivable that every single Red Hat package is untrustworthy. The dates on the packages are only as trustworthy as the key, so there is no beginning or end time for this: you must throw out all Red Hat packages on your system, because any could be compromised.

    Source really gives you very little assurance unless you compile it.

    If we want to look at this in contrast to Windows, there's not really any comparison, since we barely even begin to have a grasp of their Byzantine updating system, and couldn't even speculate as to the effects of a similar problem on their side.

  2. Re:Press Releases... by eggnoglatte · · Score: 4, Informative

    But, it doesn't matter - it's all open source, you can look at the lines of code and verify for yourself that they're safe, right?

    Wrong. I know this is common wisdom in the open source community, but it really isn't that simple when compilers are involved.

    The reason is that the hackers COULD potentially have modified the binary of the compiler used to bootstrap the whole RedHat distribution. You can modify the compiler such that it takes harmless code and compiles backdoors into it. In particular you could modify it so that it always propagates the change when it compiles a version of itself. Since every system bootstraps from an already compiled version of the compiler, a well hidden backdoor could propagate forever, unless people actually analyze the machine code.

    Read Ken Thompson's 1984(!) Turing Award lecture for the full nitty gritty details. This should be required reading for everybody in security (and all open source advocates, for that matter):

    http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.5728&rep=rep1&type=pdf
    (PDF)

  3. Re:Consider Red Hat's response vs. Debian's by Bruce+Perens · · Score: 4, Informative
    Red Hat has an accepted path to make vulnerability information available, through CERT. There are no super crackers or super vulnerabilities that you can't talk about. Probably it was like the Debian situation. Someone got sloppy and had their password sniffed. Then once on the system a privilege-escalation vulnerability was used.

    The Debian compromise lasted about two hours. The attacker had sniffed a developer password some time before then, but it wasn't until he could get root that he did anything dangerous, and he did stuff that revealed him to the site admins. The main problem was in the kernel, which had the privilege-escalation bug. Red Hat was vulnerable too.

    Bruce

  4. New Fedora Key by FrankDrebin · · Score: 5, Informative

    TFA says:

    However, as of September 8, the crisis continues, with Fedora users still unable to get security updates or bug-fixes.

    Not true. Go here: https://fedoraproject.org/wiki/Enabling_new_signing_key, follow the instructions and voila... updates available.

    --
    Anybody want a peanut?
  5. Re:Consider Red Hat's response vs. Debian's by michaelmuffin · · Score: 5, Informative

    That is ridiculous. The law does certainly not say that making money is the only thing that matters.

    i agree that it's ridiculous. it is however true.

    http://en.wikipedia.org/wiki/Dodge_v._Ford_Motor_Company

  6. How is this "ignoring FOSS"? by itsdapead · · Score: 5, Informative

    If Red Hat, one of the epitomes of a successful FOSS-based business, can ignore FOSS when to do so is corporately convenient

    Sorry, but I must have missed the clause in the GPL that requires full and immediate public disclosure of any security breach on your servers, or a duty to maintain 100% availability.

    OTOH I do remember loads of stuff in the GPL about how there was no warranty.

    There also seems to be a presumption that this "breach" represents some sort of systemic vulnerability in the Fedora/Red Hat product - TFA and several comments here reference the Debian SSL problem. What about the good old standbys of "inside job", "social engineering", "weak password" or "bugger, I knew I should have password-protected my SSH key"?

    What if they're planning to fire someones ass, or even press criminal charges over the incident? That would place serious restrictions on what they could publicly announce.

    --
    In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
  7. Re:Press Releases... by TheRaven64 · · Score: 4, Informative

    This is why the GCC build process builds the compiler three times. First it builds it with the existing compiler. Next it builds it with the new version. Finally, it builds it with the version built with itself and compares the binaries. If the last two are different, then the old compiler is likely to have been trojaned.

    --
    I am TheRaven on Soylent News