Secure Architectures and Systems - Exploiting Vulnerabilities Part 2: Trust Boundaries in Programs

class: center, middle

### Secure Computer Architecture and Systems
***
# Exploiting Vulnerabilities Part 2:<br>Trust Boundaries in Programs

???

- Hi everyone
- In this video we are going to talk about the concept of trust boundaries in programs

---
# Distrusting Command Line Parameters

- For all attacks we have seen so far, memory errors are exploited through a payload coming from the **command line**
  - **Payload**: piece of program input, can be maliciously malformed to trigger a vulnerability

???
- In most of the examples of attacks we covered previously, the payload comes from the command line
- As a reminder the payload is the malformed piece of program input that the attacker uses to trigger a vulnerability and perform an exploit
- Not trusting the validity of the number and the values of command line parameters is a well known security practice
- In the past you have probably already been checking the validity of these things to a certain extent
--
- What was our trust model?
???
- In fact, now that we are talking about distrusting some forms of inputs to the program, we can try to reason about what was our trust model for all these attack examples we saw

--
<div style="text-align:center"><img src="include/cmdline.svg" width=480 /></div>

???

- From the victim's program protection point of view, we trust the privileged layers like the OS, as well as the hardware, to work correctly
- What we did not trust wast other programs that could inject command line arguments into our victim program
- If the program is invoked by the attacker on the command line, as we have seen in our examples, this untrusted other program could be the invoking shell

---
# Distrusting Command Line Parameters

- From the program's point of view, **should not assume that anything coming from the command line is well-formed**
- An attacker could try to invoke the program with:
  - Wrong number of parameters
  - Bad combination of parameters
  - Wrong parameter values: bad type, sizes, ranges, etc.

???
- You are probably at least partially aware that a program you develop should never assume that any data flowing into the program through command line arguments is well formed
- To trigger vulnerabilities, an attacker can try to invoke the program with the wrong number of parameters, bad combination of parameters, and wrong types, sizes, ranges for certain parameters

--
- How does the implementation reacts when this happens?
  - Does the program exit gracefully, or does it go into undefined behaviour (security issues)?

???
- So as the developer of an application you need to reason about how your program reacts when something malformed is passed through the command line
- Does your program crashes or misbehaves? If so that is not good and you probably have security issues.
- The intended way to deal with these errors is to handle them gracefully, for example by printing an error message and exiting the program

--
- This is not just about the invoker making mistakes when crafting the command line
  - According to the threat model, the invoker may be malicious, and **actively input bad parameters to trigger bugs**
???

- Please also note that this is not just about the user invoking the program setting by mistake the wrong number of arguments or the wrong value for an argument
- You need to think about your trust model and assume that non trusted actors will actively try absolutely anything possible to trigger bugs in your program and subvert it

---
# Trust Boundaries in Programs

- In our scenarios the command line is a **trust boundary**
  - An interface between an untrusted component and a trusted one, according to our threat model
- That makes it a **vector of attack**

???

- The command line in our scenario is an interface between a trusted and an untrusted component
- That makes it a vector of attack

> **The validity of all data flowing through this interface needs to be checked before that data is used**

???

- and protection is required to ensure that the data flowing through this interface is valid before it can be used by the trusted component

- Sanity checks:
  - Do we have the right amount of parameters?
  - Do parameters make sense together (proper combinations)?
  - Do parameters have proper values in terms of types, ranges, format, etc.?

???

- This involves applying sanity checks on that untrusted data
- Checks like do we have the right amount of command line parameters, do the combination of parameters passed on the command line makes sense, and is the value of each parameters valid based on its type, size, range, format, etc.

---
# Trust Boundaries in Programs (2)

- **Beyond the command line, more traditional trust boundaries:**

???
- And it's not just about the command line, there are several other common sources of untrusted input in modern systems software

???
- The standard input can be used by an attacker to feed bad data to your program
- Environment variables can be manipulated
- All the data flowing into the program through disk or network I/O could be invalid, think about malformed file formats, corrupted packet metadata, there is an infinity of possibilities how things can be malformed here
- Finally, if your program is communicating with another process you don't trust through inter process communication, that is also a vector of attack

--
- Considering them depends on your threat model, but almost every production-ready program using these interfaces will need to sanitise

???

- Overall considering each of these attack vectors depends on your threat and trust models, but if you are building a production ready application which is using some of these interfaces, then you need to reason about the possibility of attack through them and implement protections

---
# Example: Command Line Arguments

.leftcol[
```c
#include <stdio.h>
#include <string.h>

// usage: ./cmdline <username> <password>
int main(int argc, char **argv) {
    char username[32];
    char password[32];

strcpy(username, argv[1]);
    strcpy(password, argv[2]);

// ...
}
```
.codelink[<a href="src/cmdline.c" download>`09-exploiting-vulnerabilities-2/cmdline.c`</a>  <a href="https://github.com/olivierpierre/comp60261-devcontainer" target="_blank" style="text-decoration: none"><img src="include/gh-logo.svg" style="height: 1em"></a>]

]

???

- We've already seen plenty of example of programs that can be subverted through wrongfully formed command line arguments
- Here we have a vulnerable program with two buffers that can be overflown

.rightcol[
```c
#define USERNAME_MAX_LEN    32
#define PASSWORD_MAX_LEN    32

int main(int argc, char **argv) {
  char username[USERNAME_MAX_LEN];
  char password[PASSWORD_MAX_LEN];

// check the number of parameters
  if(argc != 3) {
      printf("usage: %s <uname> <passwd>\n",
        argv[0]);
      return 0;
  }

// don't copy past the buffer size
  strncpy(username, argv[1], USERNAME_MAX_LEN);
  strncpy(password, argv[2], PASSWORD_MAX_LEN);

// make sure strings are properly terminated
  username[sizeof(username) - 1] = '\0';
  password[sizeof(password) - 1] = '\0';
  // ...
}
```
.codelink[<a href="src/cmdline-fixed.c" download>`09-exploiting-vulnerabilities-2/cmdline-fixed.c`</a>  <a href="https://github.com/olivierpierre/comp60261-devcontainer" target="_blank" style="text-decoration: none"><img src="include/gh-logo.svg" style="height: 1em"></a>]
]

???

- A protected version of that program is on the right of the slide
- As we can see we first validate that we have the right number of command line arguments
- Then with strncpy we make sure not to copy more bytes than the size of the receiving buffers
- And finally we make sure that the strings are properly terminated, because the attacker could pass them in such a way that they are not

---
# Example: Environment Variables

```c
#include <stdio.h>
#include <stdlib.h>

// usage: USER_INPUT=pierre ./environment-variable
int main(int argc, char *argv[]) {
    char *user = getenv("USER_INPUT");
    if (!user) {
        fprintf(stderr, "Please set the USER_INPUT environment variable.\n");
        return 1;
    }

char buffer[100];

// Vulnerable: format string comes from environment variable
    snprintf(buffer, 100, user);

printf("Hello, ");
    puts(buffer);

return 0;
}
```
.codelink[<a href="src/environment-variables.c" download>`09-exploiting-vulnerabilities-2/environment-variables.c`</a>  <a href="https://github.com/olivierpierre/comp60261-devcontainer" target="_blank" style="text-decoration: none"><img src="include/gh-logo.svg" style="height: 1em"></a>]

???

- Here is another example of bad data injection, this time through an environment variable
- We first get a pointer to the value of this environment variable named USER_INPUT with the `getenv` libc function
- Then we use snprintf to copy the value of the environment variable into buffer
- There is no possibility of overflow here because we know that `snprintf` won't write more than 100 bytes which is the size of the receiving buffer
- However snprintf takes as third parameter a format string, and possibility as fourth and more parameters a list of variables which value should be substituted to tokens in the format string, exactly like printf
- So if we pass through the environment variable something like looks like a format string with tokens
- We can leak part of the program's memory on the command line when the format string is printed
- Some of these look like pointers, and leaking pointer is an important step in many attacks as we will see in one of the next videos

---
# Example: Environment Variables (2)

```c
#include <stdio.h>
#include <stdlib.h>

char buffer[100];

*   snprintf(buffer, sizeof(buffer), "%s", user);

printf("Hello, ");
    puts(buffer);

return 0;
}
```
.codelink[<a href="src/environment-variables-fixed.c" download>`09-exploiting-vulnerabilities-2/environment-variables-fixed.c`</a>  <a href="https://github.com/olivierpierre/comp60261-devcontainer" target="_blank" style="text-decoration: none"><img src="include/gh-logo.svg" style="height: 1em"></a>]

???

- The fix here is simple, have the format string be simply `%s` and that token be replaced with snprintf by a single variable which is the value of the environment variable
- Even simpler, for copying a string just use strncpy

---
# Example: HeartBleed

- HeartBleed (CVE-2014-0160): critical vulnerability in OpenSSL that allowed remote attackers to read memory from vulnerable servers

???
- Let's have a look at one last example, this time taken from the real world
- You may have heard about the heartbleed vulnerability in the OpenSSL library that is used to encrypt most of the https traffic of the internet
- It's a very severe issue that caused a big commotion in 2014

--
- Malformed heartbeat request:
  - Malicious client controls the size of the server's response
  - Sets it larger than the response's data
  - Buffer overflow in read mode, server memory content (e.g. crypto keys) sent back to the client

???

- With heartbleed the attacker's payload comes through the network
- The attacker here controls a remote client and aims to leak sensitive data from the server
- The client regularly send a heartbeat request to the server to keep the connection alive
- The client indicates within the request the size of the response the server should send back, and sets that number to a larger value than the actual response the server will write
- This triggers and overflow in read mode on the heap of the server, and the memory read this way is sent back to the client
- It could contain anything including crypto keys that are commonly manipulated by that library

---
# Example: HeartBleed