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

Direct Download

Read full article as PDF:

Price $2.95

Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Find SysAdmin Jobs