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 Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University Systems and Internet Infrastructure Security (SIIS) Laboratory Page 1
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 ‣ Systems and Internet Infrastructure Security (SIIS) Laboratory Page 2
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 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 3
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); } Systems and Internet Infrastructure Security (SIIS) Laboratory Page 4
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 overwrite the R2 buffers (and metadata between) strncpy(buf2R1, argv[1], BUFSIZER1-1); Systems and Internet Infrastructure Security (SIIS) Laboratory Page 5
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]; }; Systems and Internet Infrastructure Security (SIIS) Laboratory Page 6
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]; }; Systems and Internet Infrastructure Security (SIIS) Laboratory Page 7
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]; }; 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)); }; y->B1 = 0xDEADBEEF; x->fnptr(buf); struct B { int B1; int B2; char info[32]; }; Systems and Internet Infrastructure Security (SIIS) Laboratory Page 9
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]; }; Systems and Internet Infrastructure Security (SIIS) Laboratory Page 10
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- ‣ on-exploit-development-and-cyber-attacks.html Systems and Internet Infrastructure Security (SIIS) Laboratory Page 11
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 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 12
Prevent Use After Free • What can you do that is not too complex? Systems and Internet Infrastructure Security (SIIS) Laboratory Page 13
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 ‣ Systems and Internet Infrastructure Security (SIIS) Laboratory Page 14
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); } Systems and Internet Infrastructure Security (SIIS) Laboratory Page 15
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 overflow) free(buf1R2); Systems and Internet Infrastructure Security (SIIS) Laboratory Page 16
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 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 17
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” ‣ 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” ‣ 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 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; // not part of memory referenced by D cast from A HexType – Jeon et al. ACM CCS 2017 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 20
Type Hierarchies • C++ allows you to construct type hierarchies Upcast Downcast HexType – Jeon et al. ACM CCS 2017 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 21
Type Hierarchies • C++ allows you to construct type hierarchies Which type of cast is safe and why? ‣ Upcast Downcast HexType – Jeon et al. ACM CCS 2017 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 22
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 Systems and Internet Infrastructure Security (SIIS) Laboratory Page 23
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(); object.filters = [filter]; flash.filters.BlurFilter = flash.filters.ConvolutionFilter; var f = object.filters; var d = f[0]; Systems and Internet Infrastructure Security (SIIS) Laboratory Page 24
Recommend
More recommend
