CO CO447 |LEC EC7 RO ROBUST APPLICATION CO CODE THROUGH AN - PowerPoint PPT Presentation

Decidable? Complete Incomplete Reports all errors Reports all errors May report false alarms Reports no false alarms Sound Undecidable Decidable Unsound May not report all errors May not report all errors May report false alarms Reports no false alarms Decidable Decidable

Over- and Underapproximations Sound Modules Reported Over-approximation of Error Behaviors . . . approximation is too False Behaviors Alarm coarse… yields too many false alarms Software

Does This Program Ever Crash? entry X ß 0 Is Y = 0 ? yes no X ß X + 1 X ß X - 1 Is Y = 0 ? yes no Is X < 0 ? exit yes no crash

Does This Program Ever Crash? entry X ß 0 Is Y = 0 ? yes no X ß X + 1 X ß X - 1 Is Y = 0 ? yes no Is X < 0 ? exit yes no infeasible path! overly imprecise crash … program will never crash

Try Analyzing Without Approximation entry X ß 0 X = 0 Is Y = 0 ? yes no X = 2 X = 1 X = 0 X ß X + 1 X ß X - 1 X = 3 X = 2 X = 1 X = 1 X = 2 X = 3 Is Y = 0 ? X = 3 X = 2 X = 1 yes no Is X < 0 ? exit yes no X = 1 X = 2 X = 3 crash non-termination! … therefore, need to approximate

Dataflow Analysis Framework dataflow elements d in X = 0 d out = f(d in ) X ß X + 1 f d out X = 1 dataflow equation transfer function

Applying the Dataflow Approach d in1 X = 0 d out1 = f 1 (d in1 ) X ß X + 1 f1 X = 1 d out1 d out1 = d in2 d in2 X = 1 Is Y = 0 ? f2 d out2 = f 2 (d in2 ) X = 1 d out2

Meet/Join Operator ⊔ d out1 = f 1 (d in1 ) d in d in d out2 = f 2 (d in2 ) 1 2 f 1 f 2 d join = d out1 ⊔ d out2 d out1 d out 2 d join d join = d in3 d in3 f 3 d out3 = f 3 (d in3 ) d out3 least upper bound operator Example: union of possible values What is the space of dataflow elements, D ? What is the least upper bound operator, ⊔ ?

Try Analyzing with “Signs ” Approximation… entry X ß 0 X = 0 Is Y = 0 ? yes no X = 0 X = 0 X ß X + 1 X ß X - 1 X = pos X = neg X = T lost Is Y = 0 ? precision X = T X = T yes no Is X < 0 ? exit yes no X = T X = T crash terminates... … but reports false alarm … therefore, need more precision

Lattices X = T true X ¹ neg X ¹ pos X = T Y ¹ 0 Y = 0 X = pos X = pos X = 0 X = 0 X = neg X = neg false X = ^ X = ^ refined signs lattice signs lattice Boolean formula lattice

Try Analyzing with “Path-sensitive signs ” entry X ß 0 true X = 0 Is Y = 0 ? yes no Y=0 X = 0 X = 0 Y ¹ 0 X ß X + 1 X ß X - 1 Y=0 X = pos X = neg Y ¹ 0 no precision loss Is Y = 0 ? Y=0 X = pos Y ¹ 0 X = neg X = neg Y ¹ 0 yes no Y=0 X = pos Is X < 0 ? exit refinement yes no X = pos Y=0 crash terminates... … no false alarm … soundly proved never crashes

Approach ches to Finding Secu curity Bugs 39 39 ¨ Runtime Monitoring ¨ Black-box Testing ¨ Static c Analysis

Fr From C m Coverity 40 40

Architecture of an Analysis Platform

Bugs Detected by Coverity 42 42 Crash sh Causi sing Defect cts Uninitialize zed va variables • • Null pointer dereference ce Inva valid use se of negative ve • • Use se after free values va • Double Do le fr free Passi ssing large parameters s by y • • Array y indexi xing errors va value • Mism smatch ched array y Under-alloca Un cations s of dyn ynamic c • • new new/del delet ete data dat Potential st stack ck ove verrun Memory y leaks ks • • Potential heap ove verrun File handle leaks ks • • Return pointers s to loca cal Network k reso source ce leaks ks • • variables va Unuse sed va values • Logica cally y inco consi sist stent co code Unhandled return co codes • • Use se of inva valid iterators •

Co Coveri rity Ch Checkers 43 43 ¨ Some coding patterns and some vulnerabilities are specific to the code base ¨ Issues that apply to the Linux kernel are unlikely to apply in application software

Ex Exampl ple Che hecker: Missi ssing ng Opti tiona nal Ar Argum guments ts 44 44 ¨ Prototype for open() syscall: int open(const char *path, int oflag, /* mode_t mode */...); ¨ Typical mistake: fd = open(“file”, O_CREAT); ¨ Force setting explicit file pe ns ! permissions ¨ Check: Look for oflags == O_CREAT without mode argument

Ex Example: chroot Protocol Check cker ¨ Goal: confine process to a “jail” on the filesystem ¤ chroot() changes filesystem root for a process ¨ Problem ¤ chroot() itself does not change current working directory chroot() chdir(“/”) open(“../file”,…) Error if open before chdir

Ta Tainting Checkers 46 46

Th The DAO 47 47 ¨ The DAO was a complex Smart Contract with a focus on fair, decentralized operations. In order to allow investors to leave the organization in the case of a disagreement, ¨ The DAO was created with an exit or a ‘split function’. This function allowed users to revert the involvement process and to have the Ether they had sent to The DAO returned. ¨ If someone wanted to leave The DAO, they would create their own Child DAOs, wait 28 days and then approve their proposal to send Ether to another address. https://coincodex.com/article/50/the-dao-hack-what-happened-and-what-followed/

Th The Hack 48 48 ¨ On June 18, it was noticed that funds were leaving The DAO and the Ether balance of the smart contract was being drained. Around 3.6M Ether worth approximately $70M were drained by a hacker in a few hours. ¨ The hacker was able to get the DAO smart contract to return Ether multiple times before it could update its own balance. ¤ There were two main flaws that allowed this to take place, firstly the smart contract sent the Ether and then updated the internal token balance. ¤ Secondly, The DAO coders had also failed to consider the possibility of a recursive call that could act in such a way. ¨ The hack resulted in the proposal of a soft fork that would stop the stolen funds from being spent, however, this never took place after a bug was discovered within the implementation protocol. This opened up the possibility of a hard fork with wider reaching implications.

Th The Hard Fork 49 49 ¨ A hard fork was proposed that would return all the Ether stolen The DAO in the form of a refund smart contract. The new contract could only withdraw and investors in The DAO could make refund requests for lost Ether. ¨ While it makes perfect sense to seek to reimburse the victims of the attack, the hard fork uncovered a number of arguments that are still prevalent in the world of cryptocurrency today. ¤ Some opposed the hard fork and argued that the original statement of The DAO terms and conditions could never be changed. ¤ They also felt that the blockchain should be free from censorship and things that take place on the blockchain shouldn’t be changed even in the event of negative outcomes. ¤ Opponents of these arguments felt that the hacker could not be allowed to profit from his actions and that returning the funds would keep blockchain projects free from regulation and litigation. ¨ The hard fork also made sense as it only returned funds to the original investors and would also help to stabilize the price of Ether.

Wha What Happe ppene ned: d: Jul July y 20 2016 50 50 ¨ The final decision was voted on and approved by Ether holders, with 89% 89% votin ing for the hard fork and as a result, it took place on July 20 2016 during the 1920000th block. ¨ The immediate result of this was the creation of Ethereum Classic ETC, 7.22% which shares all the data on the Ethereum blockchain up until block 1920000. ¨ The creation of Ethereum Classic showed that hard forks were ve very much possible and it can be said that the creation of the second Ethereum currency has had an influence on the creators of subsequent Bitcoin BTC, 7.72% forks. ¨ It also became clear that while the DAO was great idea, it was not implemented correctly and in order to move forward successfully blockchain projects would have to implement rigid security protocols.

The DAO Hack ck 51 51 ¨ The attacker was analyzing DAO.sol, and noticed that the 'splitDAO' function was vulnerable to the recursive send pattern we've described above: this function updates user balances and totals at the end, so if we can get any of the function calls before this happens to call splitDAO again, we get the in infin finit ite recursio ion that can be used to move as many funds as we want (code comments are marked with XXXXX, you may have to scroll to see em): ¨ http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/

Ca Call Sp Split Mor More than Once 52 52 The basic idea is this: propose a split. Execute the split. When the DAO goes to withdraw your reward, call the function to execute a split before that withdrawal finishes.

Moving Funds Multiple Ti Times 53 53 ¨ Basically the attacker is using this to transfer more tokens than they should be able to into their child DAO. ¨ How does the DAO decide how many tokens to move? Using the balances array of course: ¨ Because p.splitData[0] is going to be the same every time the attacker calls this function (it's a property of the proposal p, not the general state of the DAO), and because the attacker can call this function from withdrawRewardFor be before the he ba balanc nces array is upda updated , the attacker can get this code to run arbitrarily many times using the described attack, with fundsToBeMoved coming out to the same value each time.

Re Recursive Call in Ma MakerD rDAO 54 54 ¨ Our team is blessed to have Dr. Christian Reitwießner, Father of Solidity, as its Advisor. During the early development of the DAO Framework 1.1 and thanks to his guidance we were made aware of a generic vulnerability common to all Ethereum smart contracts. We promptly circumvented this so-called “recursive call vulnerability” or “race to empty” from the DAO Framework 1.1 as can be seen on line 580:

Mor More D DAOs 55 55 ¨ Three days ago this design vulnerability potential was raised in a blog post which subsequently led to the discovery of such an issue in an unrelated project, MakerDAO. This was highlighted in a reddit post, with MakerDAO being able to drain their own funds safely before the vulnerability could be exploited. ¨ Around 12 hours ago user Eththrowa on the DAOHub Forum spotted that while we had identified the vulnerability in one aspect of the DAO Framework, the existing (and deployed) DAO reward account mechanism was affected. His message and our prompt confirmation can be found here. ¨ We issued a fix immediately as part of the DAO Framework 1.1 milestone. https://blog.slock.it/no-dao-funds-at-risk-following-the-ethereum-smart-contract-recursive-call-bug-discovery-29f482d348b

Sa Sanitize I Integers Be Befor ore U Use Warn when unchecked integers from untrusted sources reach trusting sinks Network copyin(&v, p, len) Syscall packet param any<= v <= any v.tainted v.clean Use(v) memcpy(p, q, v) array[v] copyin(p,q,v) while(i < v) copyout(p,q,v) … ERROR Linux: 125 errors, 24 false; BSD: 12 errors, 4 false

Look Looking f for Bl or Block ocking F Funct ction on Ca Calls 57 57

Mi Missed Lo Lower-bo bound und Chec heck 58 58 /* 2.4.5/drivers/char/drm/i810_dma.c */ if(copy_from_user(&d, arg, sizeof(arg))) return –EFAULT; if(d.idx > dma->buf_count) return –EINVAL; buf = dma->buflist[d.idx]; Copy_from_user(buf_priv->virtual, d.address, d.used); ¨ d is read from the user ¨ Signed integer d.idx is upper-bound checked but not lower-bound checked ¨ d.used is unchecked , allowing 2GB of user data to be copied into the kernel

Re Remote Exploit 59 59 /* 2.4.9/drivers/isdn/act2000/capi.c:actcapi_dispatch */ isdn_ctrl cmd; ... while ((skb = skb_dequeue(&card->rcvq))) { msg = skb->data; ... memcpy(cmd.parm.setup.phone, msg->msg.connect_ind.addr.num, msg->msg.connect_ind.addr.len - 1); ¨ msg points to arbitrary network data ¨ This can be used to overflow cmd and write data onto the stack

Example Code with Functions and Calls 61 61 ¨ We would want to reason about the flow of the input ( si size ) and na name provided by the user

Call Graph for the Program 62 62 main atoi exit free malloc say_hello fgets printf

Control Flow Graph 63 63 char * buf[8]; Represent logical structure of code in graph form if (a) a !a b = new char [5]; if (a && b) !(a && b) a && b buf[8] = a; delete [] b; *b = ‘x’; *a = *b; END

Path Traversal 64 64 Conceptually Conceptually: Analyze each path through control graph separately char * buf[8]; Actually Perform some checking Actually computation once per node; combine paths at merge nodes if (a) a !a b = new char [5]; if (a && b) !(a && b) a && b buf[8] = a; delete [] b; *b = ‘x’; *a = *b; END

Apply Checking Null Null po poin inters Use a Us after f free 65 65 Array over Ar errun See how three checkers are run for this path char * buf[8]; if (a) Checker • !a • Defined by a state diagram, with state if (a && b) transitions and error states !(a && b) delete [] b; • Run Checker • Assign initial state to each program var • State at program point depends on state at *b = ‘x’; previous point, program actions • Emit error if error state reached *a = *b; END

Apply Checking 66 66 Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) !a if (a && b) !(a && b) delete [] b; *b = ‘x’; *a = *b; END

Apply Checking 67 67 Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) “a is null” !a if (a && b) !(a && b) delete [] b; *b = ‘x’; *a = *b; END

Apply Checking 68 68 Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) !a “a is null” if (a && b) Already knew !(a && b) a was null delete [] b; *b = ‘x’; *a = *b; END

Apply Checking 69 69 Null pointers Use after freeArray overrun char * buf[8]; “buf is 8 bytes” if (a) !a “a is null” if (a && b) !(a && b) delete [] b; “b is deleted” *b = ‘x’; *a = *b; END

Apply Checking 70 70 Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) !a “a is null” if (a && b) !(a && b) delete [] b; “b is deleted” *b = ‘x’; “b dereferenced!” *a = *b; END

Apply Checking 71 71 Null pointers Use after free Array overrun char * buf[8]; “buf is 8 bytes” if (a) !a “a is null” if (a && b) !(a && b) delete [] b; “b is deleted” *b = ‘x’; “b dereferenced!” *a = *b; No more errors reported for b END

Fa False Positives 72 72 ¨ What is a bug? Something the user will fix. ¨ Many sources of false positives ¤ False paths ¤ Idioms ¤ Execution environment assumptions ¤ Killpaths ¤ Conditional compilation ¤ “third party code” ¤ Analysis imprecision ¤ …

A False Path 73 73 char * buf[8]; if (a) a !a b = new char [5]; if (a && b) !(a && b) a && b buf[8] = a; delete [] b; *b = ‘x’; *a = *b; END

False Path Pruning 74 74 Disequality Branch Integer Range char * buf[8]; if (a) !a if (a && b) a && b buf[8] = a; END

False Path Pruning 75 75 Disequality Branch Integer Range char * buf[8]; if (a) “a in [0,0]” “a == 0 is true” !a if (a && b) a && b buf[8] = a; END

False Path Pruning 76 76 Disequality Branch Integer Range char * buf[8]; if (a) “a in [0,0]” “a == 0 is true” !a if (a && b) “a != 0” a && b buf[8] = a; END

False Path Pruning 77 77 Disequality Branch Integer Range char * buf[8]; Impossible if (a) “a in [0,0]” “a == 0 is true” !a if (a && b) “a != 0” a && b buf[8] = a; END

Ap Application to Security Bu Bugs 78 78 ¨ Stanford research project ¨ Ken Ashcraft and Dawson Engler, Using Programmer-Written Compiler Extensions to Catch Security Holes, IEEE Security and Privacy 2002 ¨ Used modified compiler to find over 100 security holes in Linux and BSD

Re Results for BSD and Linux 79 79 Linux BSD Violation Bug Fixed Bug Fixed Gain control of system 18 15 3 3 Corrupt memory 43 17 2 2 Read arbitrary memory 19 14 7 7 Denial of service 17 5 0 0 Minor 28 1 0 0 Total 125 52 12 12

Black box testing and fuzzing

Approach ches to Finding Secu curity Bugs 81 81 ¨ Runtime Monitoring ¨ Black ck-bo box T x Testing ng ¨ Static Analysis

Fuz Fuzzing ing Bas asic ics 82 82 ¨ A form of vulnerability analysis and testing ¨ Many slightly anomalous test cases are input into the target application ¨ Application is monitored for any sign of error

Ex Exampl ple 83 83 ¨ Standard HTTP GET request ¤ GET /index.html HTTP/1.1 ¨ Anomalous requests ¤ AAAAAA...AAAA /index.html HTTP/1.1 ¤ GET ///////index.html HTTP/1.1 ¤ GET %n%n%n%n%n%n.html HTTP/1.1 ¤ GET /AAAAAAAAAAAAA.html HTTP/1.1 ¤ GET /index.html HTTTTTTTTTTTTTP/1.1 ¤ GET /index.html HTTP/1.1.1.1.1.1.1.1 ¤ etc...

Ea Early Successes (1989 Fuzz Project) 84 84

IPhone Security Flaw: July 2007 85 Shortly after the iPhone was released, a group of security researchers at Independent Security Evaluators decided to investigate how hard it would be for a re remote ary to compromise ad adversar the private information stored on the device

Su Succe ccess 86 86 ¨ Within two weeks of ¨ Notified Apple of the part time work, we had vulnerability and successfully proposed a patch. ¤ discovered a ¨ Apple subsequently vulnerability resolved the issue. ¤ developed a toolchain ¨ Released an advisory for working with the iPhone's architecture ¤ created a proof-of- concept exploit capable of delivering files from the user's iPhone to a remote attacker

CVE-2007-3944 Issued and Patched 87 87

iPhone Attack ¨ iPhone Safari downloads malicious web page ¤ Arbitrary code is run with administrative privileges ¤ Can read SMS log, address book, call history, etc. ¤ Can transmit collected data to attacker ¤ Can perform physical actions on the phone n system sound and vibrate the phone for a second n could dial phone numbers, send text messages, or record audio (as a bugging device) 88

How Was This Discovered? ¨ WebKit is open source ¤ “WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.” ¨ So we know what they use for code testing ¤ Use code coverage to see which portions of code is not well tested ¤ Tools gcov, icov, etc., measure test coverage 89

Col Collect Co Coverage for or the Test Su Suite 90 90 Identify potential focus points. From development site: the JavaScriptCore Tests “ If you are making changes to JavaScriptCore, there is an additional test suite you must run before landing changes. This is the Mozilla JavaScript test suite .”

What To Focu cus? ¨ 59.3% of 13,622 lines in JavaScriptCore were covered ¤ 79.3% of main engine covered ¤ 54. 54.7% 7% of Perl Compatible Regular Expression (PCRE) covered ¨ Next step: focus on PCRE ¤ Wrote a PCRE fuzzer (20 lines of perl) ¤ Ran it on standalone PCRE parser (pcredemo from PCRE library) ¤ Started getting errors: PCRE compilation failed at offset 6: internal error: code overflow ¨ Evil regular expressions crash mobile Safari 91

Fuz Fuzzing ing in in Offic ice 92 92

Fuz Fuzzing ing for Mone ney 93 93

Mu Mutation Ba Base sed Fu Fuzzing 94 94 ¨ Success dependent on the inputs ¨ Little or no knowledge of the being modified structure of the inputs is assumed ¨ May help to get to parts of the code protected by complex ¨ Input anomalies are added to conditionals existing valid inputs ¨ May fail for protocols with ¨ Input anomalies may be checksums, those which depend completely random or follow on challenge response, etc. some heuristics ¨ Examples: ¨ Requires little to no set up time ¤ ZZUF, very successful at finding bugs in many real-world programs, http://sam.zoy.org/zzuf/ ¤ Taof, GPF, ProxyFuzz, FileFuzz, Filep, etc.

Ex Example: Fuzzing a PD PDF Viewer ¨ Google for .pdf (about 1 billion results) ¨ Crawl pages to build a corpus ¨ Use fuzzing tool (or script to) ¤ 1. Grab a file ¤ 2. Mutate that file ¤ 3. Feed it to the program ¤ 4. Record if it crashed (and input that crashed it) 95

Im Imag age e Fo Format Fuzzing? 96 96

Ru Rupture Fuz Fuzzer er 97 97 http://www.youtube.com/watch?v=dHYLu3oYpnQ&feature=youtu.be

fu fuzzdb: Attack k and Discovery y Pattern Da Databa base for Appl pplicati tion n Fuz uzz Testi ting ng 98 98 \x3C dir%00| 03C A \u003c TRUE |dir &#x0003C \u003C |dir| FALSE &#x00003C something%00html |/bin/ls -al 0 &#x000003C &apos; 00 ?x= &#x3C; /&apos; ?x=" 1 &#x03C; \&apos; -1 ?x=| ^&apos; ?x=> &#x003C; 1.0 @&apos; /boot.ini -1.0 &#x0003C; {&apos;} 2 ABCD|%8.8x|%8.8x|%8. &#x00003C; [&apos;] 8x|%8.8x|%8.8x|%8.8x| -2 &#x000003C; *&apos; -20 %8.8x|%8.8x|%8.8x|%8. &#X3C #&apos; 8x| 65536 &#X03C ">xxx<P>yyy ../../boot.ini 268435455 "><script>" -268435455 /../../../../../../../../%2A &#X003C <script>alert("XSS")</scri %25%5c..%25%5c..%25% 2147483647 &#X0003C pt> 0xfffffff 5c..%25%5c..%25%5c..% &#X00003C uname -n -s 25%5c..%25%5c..%25%5 NULL &#X000003C whoami c..%25%5c..%25%5c..%2 null &#X3C; pwd \0 5%5c..%25%5c..% &#X03C; last 25%5c..%2 \00 cat /etc/passwd < script > < / script> 5%5c..%00 &#X003C; ls -la /tmp %25%5c..%25%5c..%25% %0a &#X0003C; ls -la /home 5c..%25%5c..%25%5c..% %00 &#X00003C; ping -i 30 127.0.0.1 +%00 25%5c..%25%5c..%25%5 &#X000003C; ping 127.0.0.1 c..%25%5c..%25%5c..%2 \0 \x3c ping -n 30 \0\0 5%5c..%25%5c..%

Ge Generatio tion Bas ased Fuzzin zzing 99 99 ¨ Test cases are generated from some description of the format: RFC, documentation, grammar, etc. ¨ Knowledge of format or protocol should give better results than random fuzzing ¨ Can take significant time to set up

Ge Generatio tion Bas ased: : SPI PIKE 100 100 s_string("POST /testme.php POST /testme.php HTTP/1.1 HTTP/1.1rn"); Host: testserver.example.com Content-Length: [size_of_data] s_string("Host: testserver.example.comrn"); Connection: close inputvar=[fuzz_string] s_string("Content-Length: "); s_blocksize_string("block1", 5); s_string("rnConnection: closernrn"); s_block_start("block1"); s_string("inputvar="); s_string_variable(“string”); // inserts a s_string_variable("inputval") fuzzed string into your “SPIKE”. ; s_block_end("block1"); The string “string” will be used for the first iteration of this variable, as well as for any SPIKES where other s_string_variables are being iterated

Th The Problems With Fuzzing 101 101 ¨ Mutation based fuzzers can generate a huge number of test cases... When has the fuzzer run long enough? ¨ Generation based fuzzers generate lots of test cases, too. What happens when they’re all run and no bugs are found? ¨ How do you monitor the target application such that you know when something “bad” has happened?