I. Introduction A. goal: discussing some famous security bugs B. bugs 1. Apple goto fail bug ------------------------------------------ APPLE GOTO FAIL BUG CVE-2014-1266 (See https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2014-1266) What: does not check the signature in TLS Server Key Exchange message Consequences: allows man-in-the-middle attackers to: - spoof SSL servers by: (1) using an arbitrary private key for the signing step or (2) omitting the signing step. Affected Apple iOS 6.x before 6.1.6 ... ------------------------------------------ Why is TLS Server Key Exchange important? ------------------------------------------ APPLE'S PUBLISHED SOURCE CODE static OSStatus SSLVerifySignedServerKeyExchange( SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update( &hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update( &hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final( &hashCtx, &hashOut)) != 0) goto fail; // ...more validation ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; } ------------------------------------------ What's the problem with that code? How could it have been detected statically? ------------------------------------------ STATIC DETECTION OF GOTO-FAIL BUG? ------------------------------------------ What could have detected it dynamically? ------------------------------------------ DYNAMIC DETECTION OF GOTO-FAIL BUG? ------------------------------------------ 2. Heartbleed Bug ------------------------------------------ HEARTBLEED Vulnerability of OpenSSL Used often in implementations of SSL/TLS ------------------------------------------ Why is SSL important? ------------------------------------------ IMPACT OF HEARTBLEED "Heartbleed affected a huge number of popular websites, including: - Google, - YouTube, - Yahoo!, - Pinterest, - Blogspot, - Instagram, - Tumblr, - Reddit, - Netflix, - Stack Overflow, - Slate, - GitHub, - Yelp, - Etsy, - the U.S. Postal Service (USPS), - Blogger, - Dropbox, - Wikipedia, - the Washington Post." Source: dwheeler.com/essays/heartbleed.html ------------------------------------------ a. How Heartbeat works in SSL ------------------------------------------ KEEP-ALIVE FEATURE IN SSL Protocol client: sends arbitrary data to server server: sends back an exact copy Message format (in C): struct { HeartbeatMessageType type; uint16 payload_length; opaque payload [HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage; Sent via SSL3_RECORD: struct ssl3_record_st { unsigned int length; unsigned char *data; } SSL3_RECORD; ------------------------------------------ Why have the response be a copy? ------------------------------------------ FROM CODE OF OPENSSL tlsl_process_heartbeat(SSL *s) { unsigned char *p = /*...*/, *pl; unsigned short hbtype; unsigned int payload, padding = 16; /* ... */ /* Read type and payload length first */ hbtype = *p++; /* p points to message */ /* write the 16-bit length into payload and adds 2 bytes to p.*/ n2s(p, payload); pl = p; /* pl points to payload contents */ /* ... */ if (hbtype == TLS1_HB_REQUEST) { /* Contruct reply */ unsigned char *buffer, *bp; buffer = OPENSSL_malloc(1+2+payload+padding); bp = buffer; /* bp points to reply */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); } } ------------------------------------------ What does memcpy(bp, pl, payload) do? Who controls what the value of payload is? What does the attacker do to get more information from the server? Does the attack overwrite any buffers? ------------------------------------------ WHAT IS THE PROBLEM? Buffer over-read (CVE-126) reading past end of buffer Improper input validation (CVE-20) ------------------------------------------ b. detection ------------------------------------------ WHY WASN'T HEARTBLEED DETECTED EARLIER? The code is complex: - indirection - special memory allocation Static tools are often incomplete - heuristics can miss bugs Dynamic tools used: - mostly positive tests - code coverage - fuzzers in traditional way ------------------------------------------ c. prevention ------------------------------------------ WHAT COULD HAVE PREVENTED HEARTBLEED? (from dwheeler.com/essays/heartbleed.html) static: 1. making code simple enough for static analysis tools 1a. Taint analysis checking when inputs are used without being sanitized dynamic: 2. thorough negative testing (testing inputs that should fail) 3. fuzz testing with address checking Address sanitizer is an extra flag (-fsanitize=address) in LLVM,clang,gcc 4. Other address access detection tools - Binary simulator (Valgrind, Dr. Memory) - Guard pages (OS page faults) static: 5. Focused manual spot-checks - check that every field used is validated dynamic: 6. Fuzzing with output examination static: 7. Formal methods - specify code behavior and check it using a verifier hybrid: 8. Fuzz test several implementations at 100% branch coverage dynamic: 9. Runtime assertion checking static: 10. Use a safer programming language 11. Thorough human review ------------------------------------------ What happens if we use address sanitization in a running system and there is an attack? Would focused manual spot-checks for validation work on a large system? 3. Dirty COW (copy on write) a. attack and consequences ------------------------------------------ DIRTY COW Local privilege escalation - use a race condition in Copy-on-write mechanism. - can lead to remote execution Attack: 1. Open a root-writable, world-readable file read-only 2. Do the same in 2 (or more) threads 3a. Some thread(s) call madvise(..., MADV_DONTNEED) - so OS tries to unload the file 3b. Some thread(s) try to write file 4. Bug in OS causes it to (sometimes) ignore that the file is read-only ------------------------------------------ How can the hacker benefit if this doesn't always work? b. detection ------------------------------------------ HOW TO DETECT CONCURRENCY BUGS? Static analysis: - large number of false positives - Precise only for simple locking disciplines Dynamic analysis: - Instrument source code, check lockset and happens before - Try different inputs and scheduler combinations to search for race(s) ------------------------------------------ What's the problem with these approaches? C. summary What can we learn from all of this?