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?

3 of 81 comments (clear)

  1. Re:Maybe? by i+kan+reed · · Score: 4, Informative

    your salted password hash is just an obscured version of your password.

    Negatory. Salted hashes are not reversable without a huge damned rainbow table particular to the salt, and most passwords are hashed, not encrypted.

    There isn't actually a password to recover from that.

  2. That's how the bash issue was handled by nedlohs · · Score: 4, Informative

    That some idiot decided to publish the prenotification is just more likely when you have something in as widespread use as bash.

  3. Re:Black hat by martyros · · Score: 3, Informative

    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.

    That's why the Xen Project doesn't put the fix into version control until after the embargo period is over. Only people on the predisclosure list (or those able to listen in) would be able to learn about the vulnerability without doing their own audit of the code to find the bug themselves (which is very expensive).

    There's basically a balance to be struck. All users not on the predisclosure list (and thus who cannot update their systems until the embargo period is over) will continue to be privately vulnerable during the embargo period: anyone who happens to have dug deep enough and found the bug can still exploit it. But as soon as the announcement is made, everyone who hasn't yet updated is publicly vulnerable: Nobody has to search to find the bug, they just have to write an exploit for it. Being privately vulnerable is certainly bad, but being publicly vulnerable is far worse. The goal of the embargo period is to try to reduce the time that users are publicly vulnerable by extending the time they are privately vulnerable. Two weeks has been found to be a reasonable cost/benefit trade-off in our experience.

    --

    TCP: Why the Internet is full of SYN.