Handling critical security vulnerabilities: Three incidents

Going Critical

Article from Issue 149/2013

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. 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.”

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More