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.

  1. Go to this GoogleDoc spreadsheet template
  2. Make a copy of your own called “Vulnerability Assessment”.
  3. Share it with your instructor and course assistant so they can track your progress during class.
  4. Make sure everyone can edit the one sheet for your group.
  5. 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:

  1. Choose a vulnerability to review. Everyone takes a few minutes to review any details they need.
  2. 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.
  3. Simultaneously reveal your votes. Don’t change your vote during this! Whatever you thought independently should be what you reveal.
  4. The two people who have the most opposite votes are the first ones allowed to speak.
  5. Discuss, and come as close to a consensus as you can.
  6. Do a new discussion for every entry in the spreadsheet.
  7. 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:

Submission & Grading

Share your document with your instructor and course assistant. They might provide feedback, but this will not be graded.