Handling critical security vulnerabilities: Three incidents
Going Critical
We look at what makes a security issue critical and how upstream developers and vendors respond by examining three incidents: CVE-2013-0156, CVE-2013-0333, and rubygems.org. Moreover, we look at improvements that can make security better in the future – specifically, incident response handling.
January 2013 was a bit of a rough month for users of Ruby on Rails and rubygems.org. Two critical security flaws were found in Ruby on Rails, and rubygems.org was broken into (luckily, not by a malicious hacker). In this article, I will look at exactly what caused these security vulnerabilities and the break-in to earn "critical" ratings, what the vendors did when a critical issue came up, and what users can do to help keep their software secure.
Critical Issues
One of the most important criteria in judging whether a security issue is critical or not is the severity of exploitation (see the "CVSS2 Scores" box). An attack that allows remote code execution as a privileged user or root is a whole lot worse than a simple denial of service condition. On the other hand, a denial of service that can be triggered remotely with a single network packet and make it through the Internet (e.g., not just on the same local subnet) might also be rated "critical."
Also, you need to look at how many systems are affected. If an attack requires a non-standard configuration, that's not as bad as one that affects the default configuration, which would mean almost all systems are affected – which leads the next main question: How easy is the exploit?
[...]
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
US / Canada
UK / Australia