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?'"
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.
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)
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
Bruce Perens.
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?
According to reports, Debian detected one compromise because of a faulty rootkit that, props to the author, but it had many, many flaws. The other compromise was detected by a 'filesystem integrity check' -- if you think that inspires confidence in people then GTFO. Those hackers screwed up... basically Debian only discovered their systems were compromised by dumb luck and simplistic checks.
This is why Debian isn't used by anybody even moderately serious about system security.
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.
"Probably" meaning "you hope", because it makes Debian look better by comparison. What you are engaging in is idle speculation, but what's known is that Red Hat are very serious about security.
I would have phrased it differently: The issue isn't fully known, thus there's a problem.
There's been quite a lot of time.
That's true. The issue is can you say confidently that disclosure of the problem wouldn't put users at risk?
That's the only reasonable reason for the delay that I can see. Since these guys are usually quite reasonable I'm making the assumption that's what's going on (or something I've completely missed). It may turn out my trust was misplaced - we should know shortly. Jessee Keating just announced updates are going out to the mirrors since I last posted.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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
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.
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
Last I checked, an eToken Pro cost less than $50. I have one on my keychain. It works with OpenSSL. I can sign with it, and the private key never leaves the device. This is not rocket science. Lots of folks use smartcards rather than the eToken to do this, the eToken is just smaller and doesn't require a reader.
"Server" is the wrong word here. Debian has non-writable resources that are used to check the writable, on-net resources. These are also available for individual Debian users to create for checking their own systems, using one of the Debian security packages that is available to everyone. This again is not rocket science, it's been really cheap and easy to do since CD writing became available.
Oh yes, for more than 10 years. Debian has lots of donations of system resources, meaning entire systems and network homes for them all over the world, and more money than it needs to do this stuff.
It's more than one network, since Debian has geographical diversity, but yes various Debian systems are behind IDS, and the packages for making your own IDS are part of Debian.
You do know that you're talking about really basic security stuff, right?
Bruce Perens.