Dr. Greg Bernstein

April 18th, 2022

Software Vulnerabilities


The purpose of this Software Security chapter is to provide a structured overview of known categories of software implementation vulnerabilities, and of techniques that can be used to prevent or detect such vulnerabilities, or to mitigate their exploitation.

The purpose of this Knowledge Area is to provide an overview of security mechanisms, attacks and defences in modern web and mobile ecosystems. This overview is intended for use in academic courses and to guide industry professionals interested in this area.

General Software Vulnerabilities

Categories of Software Vulnerabilities

From CyBOK Software

  • Memory Management Vulnerabilities
  • Structured Output Generation (Injection) Vulnerabilities (see web)
  • Race Condition Vulnerabilities
  • API Vulnerabilities
  • Side-channel

Memory Management Vulnerabilities 1

From CyBOK Software

Some programming languages have constructs for allocating memory cells that can subsequently be assigned to, or read from by the program, and then deallocated again. The programming language definition specifies how to use these constructs correctly: for instance, allocation of n memory cells will return a reference to an array of cells that can then be accessed with indices 0 to n - 1 until the reference is deallocated (freed) again.

Memory Management Vulnerabilities 2

From CyBOK Software

This specification can be seen as a contract for the memory management sub-component. Some programming languages implement this contract defensively, and will throw an exception if a client program accesses memory incorrectly.

Memory Management Vulnerabilities 3

From CyBOK Software

Other programming languages (most notably, C and C++) leave the responsibility for correctly allocating, accessing and deallocating memory in the hands of the programmer, and say that the behavior of programs that access or manage memory incorrectly is undefined. Such languages are sometimes called memory unsafe languages, and bugs related to memory management are a notorious source of security bugs in these languages.

Memory Vulnerability Types

From CyBOK Software

  • A spatial vulnerability is a bug where the program is indexing into a valid contiguous range of memory cells, but the index is out-of-bounds. The archetypical example is a buffer overow vulnerability where the program accesses an array (a buffer) with an out-of-bounds index.

  • A temporal vulnerability is a bug where the program accesses memory that was once allocated to the program, but has since been deallocated. A typical example is dereferencing a dangling pointer.

Why be concerned?

From CyBOK Software

Memory management vulnerabilities are particularly dangerous from a security point of view, because in many implementations mutable memory cells allocated to the program are part of the same memory address space where also compiled program code, and runtime metadata such as the call stack are stored. In such implementations, a memory access by the program that violates the memory management contract can result in an access to compiled program code or runtime metadata, and hence can cause corruption of program code, program control flow and program data.

Memory Attack Types 1

  • In a code corruption attack, the invalid memory access modifies compiled program code to attacker specified code.

  • In a control-flow hijack attack, the invalid memory access modi€es a code pointer (for instance, a return address on the stack, or a function pointer) to make the processor execute attacker-provided code (a direct code injection attack), or to make the processor reuse existing code of the program in unexpected ways.

Memory Attack Types 2

  • In a data-only attack, the invalid memory access modifies other data variables of the program, possibly resulting in increased privileges for the attacker.

  • In an information leak attack, the invalid memory access is a read access, possibly resulting in the exfiltration of information, either application secrets such as cryptographic keys, or runtime metadata such as addresses which assist prediction of the exact layout of memory and hence may enable other attacks.

Is this still a problem?

From February 2019

Microsoft memory bugs

They’ve got this solved now right?

From May 2020

Chrome memory bugs

What Should I do?

  • Use higher level languages whenever you can: Python, JavaScript, Java, etc…

  • “If you are writing or rewriting a low-level application from scratch, always choose Rust over C or C++. Rust is a new-ish programming language that can perform low-level tasks well like C and C++, but unlike C/C++, Rust is memory-safe. This means that bounds checking is no longer required, and it is impossible to overflow variables to create potential security vulnerabilities.” From Alice and Bob learn App Sec. See Rust Language

Memory Attack Reference

  • L. Szekeres, M. Payer, T. Wei and D. Song, “SoK: Eternal War in Memory,” 2013 IEEE Symposium on Security and Privacy, Berkeley, CA, USA, 2013, pp. 48-62, doi: 10.1109/SP.2013.13. PDF. Complete guide to memory attacks.

Race Condition Vulnerabilities 1

When a program accesses resources (such as memory, files or databases) that it shares with other concurrent actors (other threads in the same process, or other processes), the program often makes assumptions about what these concurrent actors will do (or not do) to these shared resources.

Race Condition Vulnerabilities 2

Such assumptions can again be thought of as part of a specification of the program. This specification is no longer a contract between two sub-components of the program (a caller and a callee), but it is a contract between the actor executing the program and its environment (all concurrent actors), where the contract specifies the assumptions made on how the environment will interact with the program’s resources.

Race Condition Vulnerabilities 3

For instance, the specification can say that the program relies on exclusive access to a set of resources for a specific interval of its execution: only the actor executing the program will have access to the set of resources for the specified interval.

Race Condition Vulnerabilities 4

Violations of such a specification are concurrency bugs, also commonly referred to as race conditions, because a consequence of these bugs is that the behavior of the program may depend on which concurrent actor accesses a resource first (‘wins a race’). Concurrency, and the corresponding issues of getting programs correct in the presence of concurrency, is an important sub-area of computer science with importance well beyond the area of cybersecurity.

API Vulnerabilities 1

An Application Programming Interface, or API, is the interface through which one software component communicates with another component, such as a software library, operating system, web service, and so forth. Almost all software is programmed against one or more pre-existing APIs. An API comes with an (explicit or implicit) specification/contract of how it should be used and what services it offers, and just like the contracts we considered in previous subsections, violations of these contracts can often have significant consequences for security.

API Vulnerabilities 2

If the client of the API violates the contract, the software system again enters an error-state, and the further behavior of the software system will depend on implementation details of the API, and this may allow an attacker to break the security objective of the overall software system.

Side-Channel Vulnerabilities 1

A side-channel is an information channel that communicates information about the execution of a software program by means of such effects from which the program’s code abstracts. Some side-channels require physical access to the hardware executing the software program. Other side-channels, sometimes called software-based side-channels can be used from software running on the same hardware as the software program under attack.

Side-Channel Vulnerabilities 2

Closely related to side-channels are covert channels. A covert channel is an information channel where the attacker also controls the program that is leaking information through the side-channel, i.e., the attacker uses a side-channel to purposefully exfiltrate information.

Side-Chanel Additional Information

Formal Methods: Protecting Key Subsystems

“Proving” the Security of Software

  • Use formal verification
  • Uses Mathematical proof techniques
  • Issue: most software is too big and complex, but techniques are improving

Idea: Secure Important Subsystems

Start with Key Crypto Libraries

  • EveryCrypt
  • EveryCrypt Algorithms, Modern favorites such as: AES-GCM, Curve25519, Ed25519, SHA2, etc… Includes assembly language optimizations
  • Currently used by Mozilla, Wireguard, …

Verification of Crypto Protocols

  • The WireGuard VPN, being simpler than most VPNs has been subject to formal verification
  • “The protocol has been verified to possess the following security properties”:
    • Correctness, Strong key agreement & authenticity, Key-compromise impersonation resistance
    • Unknown key-share attack resistance, Key secrecy, Forward secrecy
    • Session uniqueness, Identity hiding

Web Vulnerabilities


  • SQL-Injection
  • Command Injections
  • User Uploaded Files
  • Local File Inclusion
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)

SQL-Injection References

Little Bobby Tables

See XKCD-327, Explained

Little Bobby Tables

Essence of SQL Injection 1

  • Structured Query Language (SQL) is a standard language for accessing and manipulating databases.
  • To work with relational database management systems (RDBMS) an SQL query is sent to the system in the form of a string
  • Not properly validating user input used to form the SQL string allows an attacker to insert arbitrary SQL commands!!!

Essence of SQL Injection 2

  • Note that all kinds of user information is kept in relational databases (RDBMS) including user names, emails, password hashes, etc…
  • For hands on with a RDBMS try using SQLite3 via Python. Note this is part of the Python standard library.

Injection Vulnerabilities in General 1

Injection attacks occur whenever applications suffer from insufficient user input validation so that attackers can insert code into the control flow of the application. Prevalent injection vulnerabilities for web and mobile applications are SQL and Shell injections. Due to inadequate sanitization of user input, requests to a database or shell commands can be manipulated by an attacker.

Injection Vulnerabilities in General 2

Such attacks can leak or modify information stored in the database or issue commands on a system in ways developers or operators have not intended. The main goal of injection attacks is to circumvent authentication and expose sensitive information such as login credentials, personally identifiable information, or valuable intellectual property of enterprises.

Web Page Input Example 1

See page injection.html

Comments Page

Web Page Input Example 2

  • Page takes user comments and adds them to page
  • Code does not check what user has entered
  • Try adding some HTML into page, e.g., <strong>This really is</strong> a <em>comment</em>

Web Page Input Example 3

Users can add HTML comments!

Comments Page

Web Page Input Example (HTML)

<section id="Application">
    <label>Comments:</label><textarea name="comments" rows="4" cols="20" id="Comments"></textarea>
    <button id="Add">Add</button>

<section id="CommentSection">

    let add = document.getElementById("Add");
    let commentSection = document.getElementById("CommentSection");
    let commentTA = document.getElementById("Comments");

    add.addEventListener("click", function(event) {
        let article = document.createElement("article");
        article.innerHTML = commentTA.value;

Web Page Input Example 4

Can a user run a script? Try this…

<p>My newest comment and a script.</p>
    alert("I hacked you! Ha ha.");
    console.log("You've been pwnd!");

Web Page Input Example 5

The script didn’t run! From MDN: innerHTML

Although this may look like a cross-site scripting attack, the result is harmless. HTML5 specifies that a <script> tag inserted with innerHTML should not execute.

However, there are ways to execute JavaScript without using <script> elements, so there is still a security risk whenever you use innerHTML to set strings over which you have no control.

Web Page Input Example 6

Try this…

This <strong>is</strong> a comment!</h5>
<img src='x' onerror='alert("I hacked you! Ha ha.");console.log("You have been pwnd!");'>

Web Page Input Example 7

Comments Page

What to do in this case?

Cross-site Scripting (XSS)

From Wikipedia: Cross-site Scripting

Cross-site scripting (XSS) is a type of security vulnerability typically found in web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

Persistent XSS

From Wikipedia: Cross-site Scripting

The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

Non-Persistent XSS

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability. These holes show up when the data provided by a web client, most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the content.

Cross Site Request Forgery 1

From Wikipedia: CSRF

In a CSRF attack, the attacker’s goal is to cause an innocent victim to unknowingly submit a maliciously crafted web request to a website that the victim has privileged access to. This web request can be crafted to include URL parameters, cookies and other data that appear normal to the web server processing the request.

Cross Site Request Forgery 2

From Wikipedia: CSRF

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user’s web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.

Cross Site Request Forgery 3

From Wikipedia: CSRF

A general property of web browsers is that they will automatically and invisibly include any cookies used by a given domain in any web request sent to that domain. This property is exploited by CSRF attacks in that any web request made by a browser will automatically include any cookies (including session cookies and others) created when a victim logs into a website.

Cross Site Request Forgery 4

From Wikipedia: CSRF

In the event that a user is tricked into inadvertently submitting a request through their browser these automatically included cookies will cause the forged request to appear real to the web server and it will perform any appropriately requested actions including returning data, manipulating session state, or making changes to the victim’s account.

CSRF Key Points

  • Involves a legitimate authenticated user
  • Involves a legitimate “secure” web site frequented by the user
  • Involves a malicious 3rd party that wants something from the web site owned by the user (information, money, etc…)
  • Takes advantage of vulnerabilities in authentication and authorization mechanisms used on the web

Tracking Vulnerabilities

What Can We Do?

  • Advise developers as to common security weaknesses seen so they can avoid them. The CWE effort was started in 2006.

  • Advise all users about specific software vulnerabilities in products. The CVE effort was started in 1999.

Common Weakness Enumeration (CWE) 1

From Mitre:CWE

Common Weakness Enumeration (CWE™) is a community-developed list of common software and hardware weakness types that have security ramifications. “Weaknesses” are flaws, faults, bugs, or other errors in software or hardware implementation, code, design, or architecture that if left unaddressed could result in systems, networks, or hardware being vulnerable to attack.

Common Weakness Enumeration (CWE) 2

From Mitre:CWE

The CWE List and associated classification taxonomy serve as a language that can be used to identify and describe these weaknesses in terms of CWEs. Targeted at both the development and security practitioner communities, the main goal of CWE is to stop vulnerabilities at the source by educating software and hardware architects, designers, programmers, and acquirers on how to eliminate the most common mistakes before products are delivered.

Common Weakness Enumeration (CWE) 3

From Mitre:CWE

Ultimately, use of CWE helps prevent the kinds of security vulnerabilities that have plagued the software and hardware industries and put enterprises at risk.

CWE Top 25 list

From CWE Top 25 for 2021

Top 25

Common Vulnerabilities and Exposures (CVE)

Mitre CVE home

The mission of the CVE Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog. The vulnerabilities are discovered then assigned and published by organizations from around the world that have partnered with the CVE Program.

CVE/ITU-T X.1520 1

CVE provides a structured means to exchange information security vulnerabilities and exposures, which provides common names for publicly known problems in the commercial or open source software used in communication networks, end-user devices or any of the other types of information and communication technology (ICT) capable of running software. The goal of the Recommendation is to define the use of CVE to make it easier to share data across separate vulnerability capabilities (tools, repositories and services) with this common naming.

CVE/ITU-T X.1520 2

CVE does not contain information such as risk, impact, fix information or detailed technical information. CVE only contains the standard identifier number with status indicator, a brief description and references to related vulnerability reports and advisories.

Example CVE (Heartbleed)

CVE for Heartbleed

CVE Example

National Vulnerability Database


NVD is the U.S. government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security related software flaws, misconfigurations, product names, and impact metrics.

Note: Now has a modern JSON based REST interface too.

Relation between NVD and CVE

From Mitre: NVD and CVE

Relationship – The CVE List feeds NVD, which then builds upon the information included in CVE Records to provide enhanced information for each record such as fix information, severity scores, and impact ratings. As part of its enhanced information, NVD also provides advanced searching features such as by OS; by vendor name, product name, and/or version number; and by vulnerability type, severity, related exploit range, and impact.

NVD Example Heartbleed

From NVD for Heartbleed

NVD Example

Dealing with Vulnerabilities

Common Vulnerability Scoring System (CVSS)

From Wikipedia: CVSS

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat. Scores are calculated based on a formula that depends on several metrics that approximate ease of exploit and the impact of exploit. Scores range from 0 to 10, with 10 being the most severe.

CVSS 3.1 June 2019

From CVSS 3.1 Specification

CVSS consists of three metric groups: Base, Temporal, and Environmental. The Base group represents the intrinsic qualities of a vulnerability that are constant over time and across user environments, the Temporal group reflects the characteristics of a vulnerability that change over time, and the Environmental group represents the characteristics of a vulnerability that are unique to a user’s environment.

Metric Groups

From CVSS 3.1 Specification

Attack Vector 1

See CVSS 3.1 Specification

  • Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable”…
  • Adjacent: The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical or logical network…

Attack Vector 2

See CVSS 3.1 Specification

  • Local: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability
  • Physical: The attack requires the attacker to physically touch or manipulate the vulnerable component…

CVE Prioritization

With so many CVEs being released and a limited amount of time and money to deal with them all we need to prioritize the “fixes” or “patches”.

Exploit Prediction Scoring System (EPSS) 1


The Exploit Prediction Scoring System (EPSS) is an open, data-driven effort for estimating the likelihood (probability) that a software vulnerabilities will be exploited in the wild. Our goal is to assist network defenders to better prioritize vulnerability remediation efforts. While other industry standards have been useful for capturing innate characteristics of a vulnerability and provide measures of severity, they are limited in their ability to assess threat.

Exploit Prediction Scoring System (EPSS) 2


EPSS fills that gap because it uses current threat information from CVE and real-world exploit data. The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

EPSS Model 1

From EPSS Model

EPSS Model 2

EPSS was first developed in the summer of 2019 and initially presented at BlackHat that same year. Since then, a Special Interest Group (SIG) has been working hard at FIRST to build a scalable computing infrastructure to ingest and process multiple data sources. In fact, through community partnerships and the work of EPSS SIG members, EPSS is currently collecting multiple different data sources, most of them daily

// reveal.js plugins