Vulnerability Assessment
Overview
The goal of today is to practice the art of assessing the severity of a given vulnerability. Today, you will be going through several past vulnerabilities in major software products. You will need to answer two types of questions: one from the Common Vulnerability Scoring System (CVSS), and some other questions that can help developers identify vulnerabilities in the future.
In today’s discussion, we will be covering a number of recent vulnerabilities in real products. As with everything in real life, these are messy and don’t always fit into the logical buckets we have made. Thus, the assessment of each vulnerability is ultimately subjective. But, fortunately we can mitigate that subjectivity with multiple perspectives and lively discussion.
Setup
This activity is for 4-6 people, all at one table if possible.
- Go to this GoogleDoc spreadsheet template
- Make a copy of your own called “Vulnerability Assessment”.
- Share it with your instructor and course assistant so they can track your progress during class.
- Make sure everyone can edit the one sheet for your group.
- As a group, review lecture notes and CVSS specification. Answer any general questions about how this severity scoring works.
Activity
We’re going to conduct a Planning Poker-style discussion. Here’s how that works:
- Choose a vulnerability to review. Everyone takes a few minutes to review any details they need.
- Each team member writes down their votes on the questions. No peeking at each other’s votes ahead of time, but feel free to discuss the vulnerability prior to voting for any clarifications.
- Simultaneously reveal your votes. Don’t change your vote during this! Whatever you thought independently should be what you reveal.
- The two people who have the most opposite votes are the first ones allowed to speak.
- Discuss, and come as close to a consensus as you can.
- Do a new discussion for every entry in the spreadsheet.
- In addition to CVSS, we want you to answer the following questions for each vulnerability:
- Was this vulnerability domain-specific? A domain-specific vulnerability is one that does not make any sense outside of the context of its domain. Think of it in terms of who could recognize it: any vulnerability that requires significant knowledge of the domain to recognize is domain-specific. Non-domain-specific vulnerabilities include commonly-understood ones, like XSS, SQL injection, buffer overflow, path traversal, and the like. Here are some examples:
- Domain-specific: An operating system kernel messes up its memory management algorithm such that it’s predictable and somehow causes a DoS. A non-expert in developing operating systems would not be able to recognize that.
- Not domain-specific: Memory leaks, because they are common coding mistakes
- Domain-specific: Forgetting to set certain permissions to a feature, because the domain dictates how those permissions ought to be set.
- Did the fix for this vulnerability primarily involve new code or changing code? That is, in a code inspection, would the team need to be looking for a piece of code that was missing, or written wrong? New code includes things like new functions, data structures, branches, conditions, and if-statements.
Vulnerabilities
We want you to review the following vulnerabilities, in any order:
- CVE-2011-3267 (null pointer dereference in PHP). See the Red Hat bugzilla, the CVE description, and the upstream patch.
- Chromium vulnerability. See the Chromium bug and its corresponding upstream fix
- CVE-2011-3376 in Apache Tomcat. See the Tomcat description of the vulnerability, the CVE entry , and the upstream patch
- CVE-2012-1090 in the Linux Kernel. See the Red Hat Bugzilla entry, along with the upstream patch
- CVE-2012-3507. A problem with HTTPD with error handling. See the CVE-2012-3507, the bug report and the fix
- CVE-2008-5519. A problem with HTTPD with disclosing prior HTTP responses. See the CVE the bug, and the fix
Submission & Grading
Share your document with your instructor and course assistant. They might provide feedback, but this will not be graded.