Handling critical security vulnerabilities: Three incidents
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.
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
Kernel king admits his tone has alienated volunteers, but says the demands of the process require directness.
New flaw in an old encryption scheme leaves the experts scrambling to disable SSL 3
Lennart Poettering wants to change the way Linux developers talk to each other.
Enterprise giant frees itself from ink and home PCs (and visa versa).
Mozilla’s product think tank sinks silently into history.
TODO group will focus on open source tools in large-scale environments.
New tool will look like GParted but support a wider range of storage technologies.
New public key pinning feature will help prevent man-in-the-middle attacks.
Carnegie Mellon researchers say 3 million pages could fall down the phishing hole in the next year.
The US government rolls new best-practice rules for protecting SSH.