I didn’t want to blog about this but seems like I’m forced to.
Today while I was reading Planet KDE on Google Reader, I read something quite worrisome, this blog by Boudewijn Rempt. Worrisome because it seems to depict our ex-developer Andrea “lcars” Barisani as a newbie of software security and oCERT as a scam.
Now, I have worked with Andrea quite a bit in Gentoo, and oCERT is the security handler for the xine project as well as my first contact when I find interesting things . I wouldn’t believe for an instant that Andrea would try to sneak in a backdoor in the code. Still worth noting because I do have a responsibility for the xine project, so I don’t think he’d be upset with me doublechecking the facts.
I thus asked Robert about it and he pointed out that our very own Ferris reported the failure! (and I would like to thank once again Ferris for always checking test failures, especially for security issues, it’s not the first time he catches something like that). And as Boudewijn said in the post update, Marc Deslauriers from KUbuntu identified the problem in a change from upstream that was reverted.
Okay so why am I writing this post? Well, I first protested on the blog comments to say that if the two of them never heard of Andrea or oCERT, that’s quite their problem. And that trusting upstream just because, well, it’s upstream is not always the right thing; as it turns out it was an upstream mistake after all. I also noted that the post itself was FUD against Andrea and oCERT from a spiteful upstream that tried to put the blame on malice, and that if we are to insult somebody as having not to be trusted because one patch out of a lot that Andrea coordinated before fails, then we should start looking at every project’s commits to see who has introduced which security bug and then point them out as malicious.
Interestingly enough though, expecting a reply, I noticed that the post now has no comment at all. When I posted mine there were another in Andrea’s defence with the author’s replying that even if it was a mistake he was not to be trusted; one from me with a reply from another person, my reply to that and a comment from “joe” pointing out it was upstream. That makes six comments, not zero. I checked a couple of times to make sure it wasn’t a broken cached page too.
I could think this was a bona fide mistake of the database, blog admin panel or anything like that, but as my post’s title say, you get what you ask for, and I am now to understand that Boudewijn Rempt has maliciously deleted the comments that pointed out he was just reporting a woeful reply full of FUD, and he is, thus, not to be trusted.
And if I were to apply his own logic, the whole Krita project’s code should not be trusted, it might be just one huge big backdoor. But I know some of the people working on KOffice are pretty cool and nice guys so I wouldn’t want to say that. But sure as death, I’d wish that some of Boudewijn Rempt peers in the KDE project were to actually try to teach him that this type of posts are just poison against the people who tried to help the community, maybe he’d be able to trust those. Or maybe he’ll just feel angry that I’m reusing part of his own strategy against him.
You get what you ask for, as I said.
No one ask to trust upstream, after all they wrote the hole in the first place. But as shown again, there is clearly a lack of communication between security team and upstream. And I also find strange that you would first contact some random guy (who isn’t known by upstream projects and probably don’t know the code or the specifications implemented by those project) instead of contacting those projects who are the most qualified person to help finding a solution that solves both the security issue and still makes the project fully functional.And in this story, I think it also makes a strong echo to what have happen to OpenSSL’s debian package, distributions tends to apply patches to a open source software without really understanding what they are doing, just because someone they know tells them it solves a specific problem.In other word we have three groups of people:1) upstream who write the hole in the fist place2) security experts who find the hole and write a patch3) distributions who apply the patchAnd then we go back to 1) to collect the mess. If you want things to work correctly, the process has to be changed, 2) and 3) need to ask what is the opinion of 1) about the patch, not because you can trust 1), but because the upstream code experts are 1).
Cyrille, I absolutely agree that upstream needs to be the one acknowledging the patch. I do both upstream (for xine) and downstream (for Gentoo), and I know pretty well that you do want upstream to make sure the patch is working before applying.As for contacting a security expert first, I do that mostly to assess what the problem can be; if it’s just a missing error condition, patch goes upstream straight away without more investigation. If it’s something exploitable, you might not want to let it available on the usual “clear” path without a patch working.But yes you’re right, upstream needs to acknowledge the patch, it makes no sense to just have a problem and a patch that seems to fix the issue. Indeed if you were to have access to the vendor-sec archive, the glib patch that was committed was not the first iteration.On the other hand, if the code was committed by upstream that broke their own testsuite, you really cannot blame the one who came up with the patch, the distributions who applied it, and not upstream that committed it at all.Oh I agree, distributions made a very bad thing not testing the patch, downstream really _should_ test the patches better, and I know that for first hand experience. And I also know from first hand experience that sometimes there _are_ security guys who just come up with some exploit without contacting upstream that might have fixed it already (happened with xine-ui some time ago).On the other hand, what I _really_ am upset about is the name calling. If either Marti (or Boudewijn, rephrasing) just said that distributions shouldn’t blindly patches because they are said to fix security issues (or any other issue for what matters), I’d have agreed and applauded to it.But starting out by picking on Andrea (or any other guy) who has been doing a hell of a job, accusing him of malice, of infecting sources with backdoors, and hinting that oCERT is a scam, *that* I’m upset about.
“just said that distributions shouldn’t blindly patches because they are said to fix security issues”Please read my mail, that is exactly what I said “DON’T USE PATCHES FROM UNTRUSTED SOURCES.” In any place I am accusing Andrea, again read the mail, the patch breaks functionality and this is a fact. The patch may open a back door since, for example, generated PostScript code is different when patch is applied. I have no time nor the desire of analyzing that, but the possibility is there. Do you have a slightest idea of the damage this can cause? Just consider following scenario: a print services provider, who has a carefully qualified workflow, does receive a new lcms.so because somebody is playing war games. After that, colors are no longer matching contract proof, but he doesn’t know because printers in cluster continue printing without any indication on whats going on. Two months after, he discover in dismay the new “feature” and has to discard the whole set and maybe face the fins the contract is impossing. And loss the big deal with that company that will never trust him again. Odd? not really. The patch modified postcript CRD generation, so it is certainly possible. And it is also possible legal action from PSP. That is the reason I never release patches without a clear license. Do you follow me?
Sorry but you’re just trying to weasel yourself out of the situation. The words “untrusted” and “backdoor” are pretty strong words in the context of security.And while you didn’t have time to analyze the patch, you found time to “analyze” oCERT and almost calling it a scam. You’re not even trying to justify that, and move toward an emotional story that people can relate to to show that you were right to do whatever it took.Well, let’s say a few things then: _everybody_ who took the patch and applied it without running the test is at fault. I already said before, but especially with these issues developers should be difficult to please; test _have to_ pass; if you committed the patch and tagged a beta1 release candidate without checking the tests, you’re just as fault as the rest of the distributions; any print service provider that decides to update his systems in the midst of a work is probably going to die one way or another, it so happens that I do have some clients in the business and I can’t even get them to run Windows updates on the desk machine while they’re fulfilling a contract. As for legal action, that’s what the “no warranty” clause is for.You haven’t just said “Andrea’s patch is broken, he should have asked first, distribution shouldn’t have used it”; you said ”Andrea’s patch introduces a backdoor, Andrea is not to be trusted, oCERT is a scam, and distributions were fooled”. The former, even in strong words, would have been a defensible statement; the latter is not.
Well, done, Diego. I really hate it when somebody gets beaten because of somebody elses mistakes.
“Sorry for the interruption. Apparently my comment system has a problem with some characters in the comments”.Oh the irony!.
“The patch may open a back door since”Marti, either you are not listening to our explanations of the term “backdoor” or you don’t want to.Stop talking about backdoors, learn what the term actually means. You are using it incorrectly.Thanks for the post Diego, oCERT detected the mistake as we got reports before patch release and we warned vendors about it.Apparently who accuses us forgot to check the advisory against their own product and read the following:”2009-03-02: patch found to break functionality, contacted affected vendors advising to use only beta version”Cheers