Fault Injection Techniques in Hardware & Software for Verification

1. CNIT 127: Exploit DevelopmentCh 16: Fault Injection

2. Fault Injection • Long used to verify the fault tolerance of hardware, such as • Automobile and airplane components • Coffee makers • Faults are injected through • Pins of integrated circuits • Bursts of EMI (Electromagnetic Interference) • Altered voltage levels, etc.

3. QA (Quality Assurance) • Engineers test software for weaknesses with fault injection • Automating these tests makes their work much more efficient • They also use manual auditing techniques • Reverse engineering • Source code auditing

4. Topics • Design Overview • Fault Monitoring • Putting It Together

5. Design Overview

6. Input Generation • Select input that uses esoteric and untested software features • This request uses the uncommon .ida filetype • An ISAPI filter included in IIS web server

7. Generating Input • Manual generation • Build inputs in a text editor • Time-consuming, but produces best results • Automated generation • Creating fake input with a program • May waste time on buggy input

8. Generating Input • Live capture • Inject faults directly into live network traffic • Requires complex adjustment of data size fields, checksums, etc. • Fuzz generation • Researchers noticed core dumps when using a dial-up modem during a thunderstorm • Random data injection found many new faults

9. Fault Injection • Open-source apps • Can be recompiled with special added code to improve fuzzing • Such as American Fuzzy Lop (link Fuzz 15) • Closed-source apps • Only input data is modified

10. Modification Engines • To find buffer overflows • Inject variable-sized data to elements • Use non-alphanumeric characters to delimit elements • Inject into elements, without altering delimiters

12. Defeating Input Sanitization • Repeat existing characters instead of injecting new ones

13. Fault Delivery • Nagel algorithm • Delays transmission of small datagrams so they can be grouped together • Enabled by default in Windows • Must be disabled with NO_DELAY flag • Link Ch 16a

14. Fault Monitoring

15. Using a Debugger • Good for interactive fault testing • Capture every exception, if possible • Instead of passing them to the application first ("First chance") • Access-violation exceptions are the most important • Indicate that data structures used to read or write to RAM were corrupted `

16. CNIT 127: Exploit DevelopmentCh 17: The Art of Fuzzing

17. Static Analysis • Analyzing code that is not running • Source code or binary • Many bugs found this way are unimportant in practice • Because there is no input from the user that "reaches" the buggy code • There's no easy way to determine the reachability of a bug from static analysis

18. Fuzzing is Scalable • An SMTP fuzzer can test any SMTP server • No need to rewrite it • Very simple strings may apply to many protocols • Such as "../" * 5000

19. Weaknesses in Fuzzers • Some parts of code won't be hit by a fuzzer • Because it requires special input values we don't know about • Fuzzing gets very slow if many parameters vary • Fuzzing should be supplemented by static analysis and runtime binary analysis

20. SPIKE • Builds a network packet by adding data one field at a time to a "spike" data structure • Automatically fills in size fields, checksums, etc. • Has various sending programs • Such as generic_send_tcp

21. SPIKE Functions • s_string("Hello, world!"); • Adds the literal string Hello World! to the spike • s_string_variable("MESSAGE"); • Adds a series of varying strings to the spike • The first one is MESSAGE • s_readline(); • Reads a message from the server

22. Very Simple SPIKE Script • Enough to fuzz "Vulnerable Server"

23. X-Query (for Unix) • Capture with WireShark

24. Spike Script (Partial)

25. CNIT 127: Exploit DevelopmentCh 18: Source Code Auditing

26. Cscope • A source code browsing tool • Useful for large code trees, such as the whole Linux kernel • Many useful search functions • Links Ch 18a, 18b

28. Ctags • Indexes source code • Works in many languages • Link Ch 18c

29. Automated Source Code Analysis Tools

30. Splint • Badly out-of date (last revised in 2007) • Output a little hard to understand • Links Ch 18d, 18e

31. Many available, specialized by language • Link Ch 18f

32. Easy to use • Finds about half the obvious vulnerabilities we've exploited

33. Heap Overflow

34. Finds Some Vulnerabilities • But not the overflow!

35. Format String Vulnerability • It doesn't find it at all!

36. Vulnerability Classes

37. Generic Logic Errors • Requires good understanding of an application • And internal structures and classes • Example: wildcard certificates • Pascal-based CA will sell a certificate for *\0.evil.com • C-based browser will see it as *, a wildcard • Link Ch 18g

38. (Almost) Extinct Bug Classes • Unbounded memory copy functions • strcpy(), sprintf(), strcat(), gets(), … • Hunted nearly to extinction

39. Root Cause (from Microsoft)

40. Bypassing ASLR & DEP

41. Format Strings • Easy to find with a code audit • Although cppcheck failed • Often found in logging code • Vulnerable only if attacker controls the format string

42. Generic Incorrect Bounds-Checking • Coder attempts to check limits, but does it incorrectly • Example: Snort RCP Processor (2003) • Processes a series of RPC fragments • Checks each fragment to make sure it's not larger than the buffer • But it should check the total size of all combined fragments

43. Snort RCP Processor (2003)

44. Loop Constructs • Coders often use intricate loops, and loops within loops • Complex interactions can lead to insecurities • Led to a buffer overflow in Sendmail • Link Ch 18h

45. Demonstration Exploit • Link Ch 18i

46. Off-by-One Vulnerabilities • Often caused by improper null-termination of strings • Frequently found in loops or introduced by common string functions • Can lead to arbitrary code execution

47. Example from Apache • When both if statements are true • Space allocated is one byte too small • memcpy will write one null out of bounds

48. OpenBSD ftp Daemon • If last character is a quote, it can be written past the bounds of the input buffer

49. strncat() • Strncat always null-terminates its output string • Will write a null byte out of bounds unless the third argument is equal to the remaining space in the buffer minus one byte

50. Non-Null Termination Issues • If a string is not terminated with a null • Memory after the string is interpreted as part of the string • May increase length of string • String writes may corrupt memory outside the string buffer • Can lead to arbitrary code execution