Slashdot Mirror
Xen Cloud Fix Shows the Right Way To Patch Open-Source Flaws
darthcamaro writes Amazon, Rackspace and IBM have all patched their public clouds over the last several days due to a vulnerability in the Xen hypervisor. According to a new report, the Xen project was first advised of the issue two weeks ago, but instead of the knee jerk type reactions we've seen with Heartbleed and now Shellshock, the Xen project privately fixed the bug and waited until all the major Xen deployments were patched before any details were released. Isn't this the way that all open-source projects should fix security issues? And if it's not, what is?
The XenProject security process gives them time to patch their systems (in this case, 2 weeks). If you don't have your stuff patched by then, they won't wait for you.
TCP: Why the Internet is full of SYN.
Their hysteria drive news cycle.
I mean, some open source projects don't actually have anyone doing live support and a patch happens when someone "gets around to it".
And some exploits are out there whether you say anything or not. Slashdot users pretty regularly complain about this with bumper sticker wisdom about "security through obscurity".
And just because the deployments are all fixed, doesn't mean someone has used that. Heartbleed(cited in the summary) was fixable within a couple days on every major linux distro with a simple update. That didn't mean no one got hacked.
All-in-all, sure it's a good policy, but not the magic perfect, oh-lets-all-be-like-xen thing the summary makes it out to be.
Sure, it's an ideal situation where a bug was identified, fixed quickly and a patch pushed out and applied by large users quickly but Xen is a program which is much more centrally controlled than BASH or OpenSSL. BASH and OpenSSL are more key infrastructure bits than Xen is. What I mean is that they are integrated into FAR more devices and systems making a silent patch nearly impossible.
the Xen project privately fixed the bug and waited until all the major Xen deployments were patched before any details were released. Isn't this the way that all open-source projects should fix security issues?
I do see value in that approach. When a vulnerability is found, it's better to report it discretely to the authors. Shouting the details to the world in the name of "openness" just causes script kiddies to go wild and nuke a bunch of machines which could have been otherwise avoided.
The question is whether black hat hackers are aware of the security holes.
Since Open Source projects communicate in the open (even if just version control commits), I find it quite likely that all major security-related projects are monitored by black hat hackers. The few weeks waiting period gives them ample time to use the security hole.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I'm sure the Xen project can keep track of all of its major players and inform them ahead of time. And nobody is a "minor player" with something so complex as Xen. It's complex enough that most users probably have support contracts with larger users. It's a lot easier to discreetly distribute a patch to that audience than to literally nearly every SSL server on the internet or every Linux user.
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
Ignorance is not bliss
I didn't want to know that!
That some idiot decided to publish the prenotification is just more likely when you have something in as widespread use as bash.
Predisclosure is very risky. You don't really know which members of your "predisclosure list" have good control over who finds out and which don't. And even with perfect control, if you're going to patch something the size of Amazon at all, you're going to have to tell a lot of people. Are you sure you want every individual who happens to have a certain job at Amazon to have the chance to exploit other people's systems?
You're not really trusting organizations. You're trusting collections of individuals. And with that many individuals, you are going to have some bad actors. But you'd have a problem even if you could think of organizations as units with perfect policy enforcement. Suppose the NSA comes to you and says they're running a big Xen cluster (they probably are somewhere). And it's critical to national and maybe global security (it could very possibly be). Do they get on the list? How are you going to feel when they use that preannouncement to break into somebody else's system?
Furthermore, people inferred that there was probably a Xen vulnerability from Amazon's downtime, before the official announcement. So how, exactly, was that better than having the Xen project actually announce that fact, with or without details or a patch?
Also, it's not so easy to really know what's a "critical deployment". The fact is that, whether you're Xen or you're bash, you don't really know who's using your stuff. You don't really know what's critical. And you definitely don't know who's trustworthy.
And all of THAT assumes that you even control the disclosure at all. If you find a problem in your software, that problem is "new to you". That does not mean that a bunch of other people don't already know about it. Especially the sort of people who make a business of exploiting these things. So you don't even know for sure who you're depriving of the knowledge.
There's always an exception. Maybe Xen is that exception. But the idea that predisclosure should be the normal approach for software in general, whether open source or otherwise, is a very dangerous one.
The problem is "security researchers" want to gain notoriety so they can make more money as consultants and doing paid appearances. The way you do that is irresponsible disclosure that causes a big stir. If you tell someone I discovered heartbleed they have heard of that and will take it as a credibility indicator. If you tell them I discovered XSA-128 everyone says never heard of it. It's all about marketing and PR and making bucks. That's how these things end up with catchy names. The people doing this are acting rationally but with questionable motives and their dedication to actual security should be under great scrutiny.
This is the right way to handle things, yes. The problem is that most researchers are used to dealing with proprietary software vendors whose reaction to any bug report is at best to ignore and bury the report and deny there's any problem, at worst to attack and sue the researchers. The only sane reaction to that situation is to handle things the way Heartbleed and Shellshock were: immediately publicly disclose all the details so that there are too many independent confirmations and too much publicity for the vendor to ignore the situation or deny the problem. When 99% of the time you need to follow one course, it's easy to lose track of when you're dealing with the other 1%.
Pick any random Linux box, and it will have bash/openssl installed.
Xen on the other hand, rather specialized software, hence you have a couple of mega-users. It's easy to coordinate with a couple of professional organisations that are critically interested.
Without such usage clusters, it's much more difficult.