CMPSC 497 Other Memory Vulnerabilities Trent Jaeger Systems and - - PowerPoint PPT Presentation

cmpsc 497 other memory vulnerabilities
SMART_READER_LITE
LIVE PREVIEW

CMPSC 497 Other Memory Vulnerabilities Trent Jaeger Systems and - - PowerPoint PPT Presentation

Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA CMPSC 497 Other Memory Vulnerabilities Trent Jaeger


slide-1
SLIDE 1

Systems and Internet Infrastructure Security (SIIS) Laboratory Page

Systems and Internet Infrastructure Security

Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA

1

CMPSC 497 Other Memory Vulnerabilities

Trent Jaeger Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University

slide-2
SLIDE 2

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 2

Memory Error

  • A memory error allows a program statement to

access memory beyond that allocated for the variables processed in the statement

  • Common case: Buffer overflow
  • But, there are other ways to exploit memory

errors to access unauthorized memory

  • No need to overflow a buffer
  • Two examples
  • Use-after-free
  • Type confusion
slide-3
SLIDE 3

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 3

Use After Free

  • Flaw: Program frees data on the heap, but then

references that memory as if it were still valid

  • Accessible: Adversary can control data written

using the freed pointer

  • Exploit: Another “write-what-where” vulnerability
slide-4
SLIDE 4

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 4

Use After Free

  • What happens here?

int main(int argc, char **argv) { char *buf1R1; char *buf2R1; char *buf2R2; char *buf3R2; buf1R1 = (char *) malloc(BUFSIZER1); buf2R1 = (char *) malloc(BUFSIZER1); free(buf2R1); buf2R2 = (char *) malloc(BUFSIZER2); buf3R2 = (char *) malloc(BUFSIZER2); strncpy(buf2R1, argv[1], BUFSIZER1-1); free(buf1R1); free(buf2R2); free(buf3R2); }

slide-5
SLIDE 5

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 5

Use After Free

  • When the second R1 buffer (buf2R1) is freed that

memory is available for reuse right away

buf1R1 = (char *) malloc(BUFSIZER1); buf2R1 = (char *) malloc(BUFSIZER1); free(buf2R1);

  • Then, the R2 buffers are allocated within that

memory region (buf2R1s)

buf2R2 = (char *) malloc(BUFSIZER2); buf3R2 = (char *) malloc(BUFSIZER2);

  • Finally, the write using the freed pointer will
  • verwrite the R2 buffers (and metadata between)

strncpy(buf2R1, argv[1], BUFSIZER1-1);

slide-6
SLIDE 6

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 6

Use After Free

  • Most effective attacks exploit data of another type

struct A { void (*fnptr)(char *arg); char buffer[40]; }; struct B { int B1; int B2; char info[32]; };

slide-7
SLIDE 7

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 7

Use After Free

  • Free A, and allocate B does what?

struct A { x = (struct A *)malloc(sizeof(struct A)); void (*fnptr)(char *arg); free(x); char buffer[40]; y = (struct B *)malloc(sizeof(struct B)); }; struct B { int B1; int B2; char info[32]; };

slide-8
SLIDE 8

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 8

Use After Free

  • How do you think you exploit this?

struct A { x = (struct A *)malloc(sizeof(struct A)); void (*fnptr)(char *arg); free(x); char buffer[40]; y = (struct B *)malloc(sizeof(struct B)); }; struct B { int B1; int B2; char info[32]; };

slide-9
SLIDE 9

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 9

Use After Free

  • How do you think you exploit this?

struct A { x = (struct A *)malloc(sizeof(struct A)); void (*fnptr)(char *arg); free(x); char buffer[40]; y = (struct B *)malloc(sizeof(struct B)); }; y->B1 = 0xDEADBEEF; x->fnptr(buf); struct B { int B1; int B2; char info[32]; };

slide-10
SLIDE 10

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 10

Use After Free

  • Adversary chooses function pointer value
  • Adversary may also choose address for buf
  • To implement a write-what-where

struct A { x = (struct A *)malloc(sizeof(struct A)); void (*fnptr)(char *arg); free(x); char buffer[40]; y = (struct B *)malloc(sizeof(struct B)); }; y->B1 = 0xDEADBEEF; x->fnptr(buf); struct B { int B1; int B2; char info[32]; };

slide-11
SLIDE 11

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 11

Use After Free

  • Flaw: program frees data on the heap, but then

references that memory as if it were still valid

  • Accessible: Adversary can control data written

using the freed pointer

  • Exploit: Another “write-what-where” vulnerability
  • Become a popular vulnerability to exploit – over

60% of CVEs

  • http://blog.tempest.com.br/breno-cunha/perspectives-
  • n-exploit-development-and-cyber-attacks.html
slide-12
SLIDE 12

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 12

Prevent Use After Free

  • Difficult to detect because these often occur in

complex runtime states

  • Allocate in one function
  • Free in another function
  • Use in a third function
  • Are all uses accessing a valid (not freed) reference?
  • In all possible runtime states
  • It is not fun to check source code for all possible

pointers

slide-13
SLIDE 13

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 13

Prevent Use After Free

  • What can you do that is not too complex?
slide-14
SLIDE 14

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 14

Prevent Use After Free

  • What can you do that is not too complex?
  • You can set all freed pointers to NULL
  • Then, no one can use them after they are freed
slide-15
SLIDE 15

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 15

Related Problem: Double Free

  • What is going on here?

main(int argc, char **argv) { … buf1R1 = (char *) malloc(BUFSIZE2); buf2R1 = (char *) malloc(BUFSIZE2); free(buf1R1); free(buf2R1); buf1R2 = (char *) malloc(BUFSIZE1); strncpy(buf1R2, argv[1], BUFSIZE1-1); free(buf2R1); free(buf1R2); }

slide-16
SLIDE 16

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 16

Double Free

  • Free the R1 buffers

free(buf1R1); free(buf2R1);

  • Allocate a new buffer R2 and supply data

buf1R2 = (char *) malloc(BUFSIZE1); strncpy(buf1R2, argv[1], BUFSIZE1-1);

  • Free the R1 again, which uses R2 data as metadata

free(buf2R1);

  • Then, free R2 which uses really messed up metadata

enabling a write-what-where attack (like heap

  • verflow)

free(buf1R2);

slide-17
SLIDE 17

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 17

Double Free

  • So, “double free” achieves the same effect as the

heap overflow vulnerabilities

  • So, can be addressed in the same way
  • But, you can also save yourself some headache by setting

freed pointers to NULL

  • But, we are only still talking about this
  • https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?

pageId=87152148

  • Hopefully, will be part of systems in the near future, but

people don’t like to tinker with the C language spec

slide-18
SLIDE 18

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 18

Type Confusion

  • Cause the program to process data of one type

when it expects data of another type

  • Provides same affect as we did with use-after-free
  • But, without the “free” – just need an ambiguous “use”
slide-19
SLIDE 19

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 19

Type Confusion

  • Cause the program to process data of one type

when it expects data of another type

  • Provides same affect as we did with use-after-free
  • But, without the “free” – just need an ambiguous “use”
  • Where’s the error below?

class Ancestor { int x; } class Descendent : Ancestor { int y; } Ancestor *A = new A; Descendant *D = static cast <Ancestor *> A; D->y = 7;

HexType – Jeon et al. ACM CCS 2017

slide-20
SLIDE 20

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 20

Type Confusion

  • Cause the program to process data of one type

when it expects data of another type

  • Provides same affect as we did with use-after-free
  • But, without the “free” – just need an ambiguous “use”
  • Where’s the error below?

class Ancestor { int x; } class Descendent : Ancestor { int y; } Ancestor *A = new A; Descendant *D = static cast <Ancestor *> A; D->y = 7; // not part of memory referenced by D cast from A

HexType – Jeon et al. ACM CCS 2017

slide-21
SLIDE 21

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 21

Type Hierarchies

  • C++ allows you to construct type hierarchies

HexType – Jeon et al. ACM CCS 2017

Upcast Downcast

slide-22
SLIDE 22

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 22

Type Hierarchies

  • C++ allows you to construct type hierarchies
  • Which type of cast is safe and why?

HexType – Jeon et al. ACM CCS 2017

Upcast Downcast

slide-23
SLIDE 23

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 23

Type Confusion Safety

  • Upcasts are always safe because they only reduce

the type structure

  • That is, subtypes extend the structure definitions only
  • Thus, downcasts (as in the example) and arbitrary

casts (that do not follow the hierarchy) are unsafe

  • However, programming environments trust

programmers to do the right thing

slide-24
SLIDE 24

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 24

Type Confusion (Flash)

  • Flash is notorious for type confusion vulnerabilities
  • From reading
  • https://googleprojectzero.blogspot.com/2015/07/one-

perfect-bug-exploiting-type_20.html

var filter = new flash.filters.BlurFilter();

  • bject.filters = [filter];

flash.filters.BlurFilter = flash.filters.ConvolutionFilter; var f = object.filters; var d = f[0];

slide-25
SLIDE 25

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 25

Type Confusion (Flash)

  • What does this code do?
  • Creates a “BlurFilter” assigned to object.filters

var filter = new flash.filters.BlurFilter();

  • bject.filters = [filter];
  • Resets constructor BlurFilter to ConvolutionFilter

flash.filters.BlurFilter = flash.filters.ConvolutionFilter;

  • Getter method called creates an ConvolutionFilter
  • bject instead

var f = object.filters; var d = f[0];

slide-26
SLIDE 26

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 26

Type Confusion (Flash)

  • What does this code do?
  • Creates a “BlurFilter” assigned to object.filters

var filter = new flash.filters.BlurFilter();

  • bject.filters = [filter];
  • Resets constructor BlurFilter to ConvolutionFilter

flash.filters.BlurFilter = flash.filters.ConvolutionFilter;

  • Getter method called here creates an

ConvolutionFilter object instead – so, what is f?

var f = object.filters; var d = f[0];

slide-27
SLIDE 27

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 27

Type Confusion (Flash)

  • So what is f? Can be a lot of things

int quality float blurX float blurY int scolor int hcolor <super> Bevel Filter <internal> int posX int posY BitmapData *bitmap <super> Displacement MapFilter

slide-28
SLIDE 28

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 28

Type Confusion (Flash)

  • Attack goal is to modify the vtable in BitmapData

(or any object) to control the program execution

int quality float blurX float blurY int scolor int hcolor <super> Bevel Filter <internal> int posX int posY BitmapData *bitmap <super> Displacement MapFilter … void *bits … <vtable> BitmapData

slide-29
SLIDE 29

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 29

Type Confusion (Flash)

  • By accessing hcolor and scolor fields, we can

compute the bitmap pointer

int quality float blurX float blurY int scolor int hcolor <super> Bevel Filter <internal> int posX int posY BitmapData *bitmap <super> Displacement MapFilter

slide-30
SLIDE 30

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 30

Type Confusion (Flash)

  • Can retrieve vtable by setting the bitmapData

address to posX and posY and read matrix

int quality float *matrix int matY int matX <super> Convolution Filter <internal> int posX int posY BitmapData *bitmap <super> Displacement MapFilter … void *bits … <vtable> BitmapData

slide-31
SLIDE 31

Systems and Internet Infrastructure Security (SIIS) Laboratory Page

Type Confusion (Flash)

  • Then, idea is to create a matrix referencing the

BitmapData as a vtable of your choice

<internal> int posX int posY BitmapData *bitmap <super> Displacement MapFilter … void *bits … <vtable> BitmapData int quality float *matrix int matY int matX <super> Convolution Filter

slide-32
SLIDE 32

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 32

Preventing Type Confusion

  • Casts may be checked at runtime to verify that

they are safe

  • Research project: HexType converts all static checks

to runtime checks

  • Is it true that we only want to allow (safe) upcasts

if programmers manually create unsafe casts?

  • Or are these just programmer errors?
  • Can some forms of downcasts or arbitrary casts be

made safe?

  • Determining an acceptable policy that balances

function and security can be hard

slide-33
SLIDE 33

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 33

Format String Vulnerabilities

  • Who uses printf in their programs?

printf ("This class is %s\n", string);

  • In some cases, printf can be exploited
slide-34
SLIDE 34

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 34

Format String Vulnerabilities

  • Who uses printf in their programs?

printf ("This class is %s\n", string);

  • In some cases, printf can be exploited
  • Printf takes a format string and an arbitrary

number of subsequent arguments

  • Format string determines what to print
  • Including a set of format parameters
  • Arguments supply input for format parameters
  • Which may be values (e.g., %d) or references (e.g., %s)
  • An argument for each format parameter
slide-35
SLIDE 35

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 35

Format String Vulnerabilities

  • Who uses printf in their programs?
  • In some cases, printf can be exploited
  • As usual, arguments are retrieved from the stack
  • What happens when the following is done?

printf(“%s%s%s%s”);

slide-36
SLIDE 36

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 36

Format String Vulnerabilities

  • Who uses printf in their programs?
  • In some cases, printf can be exploited
  • As usual, arguments are retrieved from the stack
  • What happens when the following is done?

printf(“%s%s%s%s”);

  • Traditionally, compilers do not check for a match

between arguments and format string – do now…

  • So, printf would print “strings” using next four values
  • n stack as string addresses – whatever they are
slide-37
SLIDE 37

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 37

Printf and the Stack

… Arg 3 Arg 2 Address of Format str

  • Remember these are

parameters to a function call

  • So, the function expects

them on the stack

  • Printf will just start reading

whatever is above the format string address

Arg 1

slide-38
SLIDE 38

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 38

Format String Vulnerabilities

  • Who uses printf in their programs?
  • In some cases, printf can be exploited
  • As usual, arguments are retrieved from the stack
  • What happens when the following is done?

printf(arg);

slide-39
SLIDE 39

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 39

Format String Vulnerabilities

  • Who uses printf in their programs?
  • In some cases, printf can be exploited
  • As usual, arguments are retrieved from the stack
  • What happens when the following is done?

printf(arg);

  • Printf can take a variable as an argument – treated

as a format string

  • If an adversary can control this argument and put

values on the stack, they can direct printf to access that memory – “%s%s%s…”

slide-40
SLIDE 40

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 40

Format String Vulnerabilities

  • Who uses printf in their programs?
  • In some cases, printf can be exploited
  • As usual, arguments are retrieved from the stack
  • What happens when the following is done?

printf(arg);

  • An interesting format parameter type – %n
  • “%n” in a format string tells the printf to write the

number of bytes written via the format string processing up to that point to an address specified by the argument

slide-41
SLIDE 41

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 41

Printf and the Stack

… Arg 3 Arg 2 Address of Format str

  • Suppose format string

generates an adversary- controlled number of bytes

  • Suppose adversary controls

Arg1-Arg3 on stack

  • Adversary can control number
  • f bytes generated by format

string with Arg1 and Arg2

  • Adversary can direct where to

write that number (of bytes) using %n with address at Arg3

Arg 1

slide-42
SLIDE 42

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 42

Printf-oriented Programming

… Arg 3 Arg 2 Address of Format str

  • If the program has a loop

that calls printf under adversary control

  • An adversary can supply

inputs to write to any memory address

  • Over and over
  • To control the execution of

the program arbitrarily (Turing complete)

Arg 1

slide-43
SLIDE 43

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 43

Prevent Format String Vulnerabilities

  • Preventing format string vulnerabilities means

limiting the ability of adversaries to control the format string

  • Hard-coded strings w/ no arguments – when you can
  • Hard-coded format strings at least – no printf(arg)
  • Do not use %n
  • Be careful with other references - %s and sprintf can be used

to created disclosure attacks

  • Compiler support to match printf arguments with

format string

slide-44
SLIDE 44

Systems and Internet Infrastructure Security (SIIS) Laboratory Page 44

Take Away

  • There are other ways to implement powerful

attacks besides overflow vulnerabilities

  • We examined a few of the common ones
  • Use-after-free and double-free
  • Type confusion
  • Format string vulnerabilities
  • Each are capable of implementing write-what-

where attacks that give an adversary arbitrary control of memory

  • We will want to prevent these vulnerabilities