Evaluating Modern Address Space Integrity Protections within the Common Criteria

1. Evaluating Modern Address Space Integrity Protections within the Common Criteria Ashley Fox CSC Australia

2. Ashley Fox • Common Criteria Evaluator within CSC Australia’s Evaluation Facility • Background in Vulnerability Assessment and Software Security

3. Agenda • Memory corruption vulnerabilities • Identification and Exploitation • Mitigations • Evaluating mitigations within the CC

4. Background • The Common Criteria is designed to provide a degree of Assurance within a Security Product • Assurance gained through evaluation of procedures, processes, development, implementation etc. • Evaluations generally include independent testing and penetration testing of the product

5. Memory Corruption Vulnerabilities • Vulnerability introduced into a product during the implementation phase • Typically affect software written in C or C++ • Generally the result of mismanagement of user input or memory allocation within a piece of software • Affects almost all product types indiscriminately • Network services • Client applications • Hardware appliances • Long time problem – Morris Worm of 1988

6. Memory Corruption Vulnerabilities • Several classes of memory corruption vulnerabilities • Some examples: • Stack Based buffer overflow • Heap Based buffer overflow • Format String issues • Integer Manipulation Issues • Allows an attacker to alter the state of a running process • Can alter the process to facilitate execution of code of attacker’s choosing

7. What do memory corruption vulnerabilities look like? • For those of you unfamiliar the next few slides show some example vulnerabilities of the types discussed previously

8. Stack Based Buffer Overflow

9. Heap Based Buffer Overflow

10. Integer Manipulation Errors

11. Format String Vulnerabilities

12. Software Complexity • Software is large and complex in nature • Projects may have many different developers over long periods of time • Projects may experience changes in requirements, goals, methodology over time • Assumptions change or are incorrect initially

13. Identifying Memory Corruption Vulnerabilities • Some vulnerabilities are very easy to identify • Some vulnerabilities hide for decades • Attackers are actively looking for these vulnerabilities • Within the realm of low attack potential? • Within the realm of an “obvious” vulnerability?

14. Identifying Memory Corruption Vulnerabilities • There are a few simple ways memory corruption vulnerabilities can be discovered • Source Code • “Grep” through source for dangerous function calls, strcpy etc. • Static Analysis tools – RATS, splint etc. • Automated Tools aka “fuzzers” • Tools that automate vulnerability hunting • Some are as simple as random byte generators • Others are quite complex • Many available freely on the Internet.

15. Constructing Exploit Code • Exploit development can be easy • Many examples to base an exploit can be found on the Internet • Generally requires • Reading public domain papers on buffer overflows etc. • Limited understanding of programming principles • Access to a debugger • Access to a compiler • Process can be as simple as: • Find input that crashes an application using a fuzzer • Use a debugger to find code and data within a process memory space • Take an exploit off the Internet and modify it to suit

16. Challenges with Memory Corruption Vulnerabilities • An attacker only needs to find one memory corruption vulnerability to be successful • Defenders need to eradicate or mitigate them all • Developer awareness is increasing • Arguably attacker awareness is increasing faster • Modern languages such as Java and C# make memory management significantly easier • There is a lot of code written in C and C++

17. Defense in Depth • A defense in depth strategy is needed to mitigate this risk • It’s proven extremely difficult to eradicate these problems from our source trees completely • Developers make mistakes like everybody else • Several defenses have been researched and implemented • The two investigated in this presentation are: • Address Space Layout Randomisation • Stack and Heap cookies

18. Address Space Layout Randomisation • Exploiting a memory corruption vulnerability usually requires knowledge of how a process exists in memory • In order to hijack a process an attacker must know the location in memory of code to execute • Address Space Layout Randomisation exploits this requirement and randomises the locations of code and data in memory

19. Address Space Layout Randomisation • In order to redirect execution flow an attacker must be able to find somewhere beneficial to redirect to • Failed attempts generally result in an application crash • Reduced risk of exploitation • Developing an exploit still within the realm of low attack potential? I would argue not

20. Stack and Heap Cookies • Protect important metadata within an application’s address space • Place a randomly generated value in front of important metadata • Before using the metadata the random value is checked to see if it has been altered • The process is terminated before the metadata is used if it has been altered

21. Stack and Heap Cookies • In order to overflow metadata an attacker is required to successfully predict the value of a cookie • Failed attempts generally result in program termination • Reduced risk of exploitation • Again we are moving outside the realm of low attack potential

22. Implementation • Several major vendors have implemented these mitigations • Open Source and Commercial Implementations • These features exist in COTS software

23. Implementations • Heap Protections • Windows XP SP2 • Windows Vista • GNU Lib C • Stack Protections • Stack Guard • GCC ProPolice / Stack-Smashing Protector (SSP) • Visual Studio • Address Space Layout Randomisation • Windows Vista • GRSecurity/PAX (3rd Party Linux kernel patch) • Exec-shield • OpenBSD

24. Evaluation of Mitigation Technologies • How do we evaluate these technologies? • First we must note several aspects of their implementation • The mechanisms are there to provide attack resistance not immunity (although they may render some vulnerabilities unexploitable this can never be guaranteed) • Both are inherently probabilistic in nature • There are solid metrics we can use in comparison of implementations (Number of bits of entropy, source of entropy etc.) • There are several works in the literature providing analysis of the effectiveness of these mechanisms • These mechanisms can be described in terms of Security Functional Requirements • The functions require a Strength of Function claim

25. Mitigation Technologies – SFRs or SARs ? • Two approaches to evaluating the technologies • SAR • Evaluate the functionality as a development methodology and tool aka ALC_TAT • SFR • Evaluate the functionality as a security functional requirement, eg an explicit requirement similar to those in the FPT class • I favor the SFR approach • Means other products can use the functionality in the form of an environmental SFR • Strength of Function claims made for the SFR

26. Example Security Functional Requirements • The TSF shall provide [assignment: number of bits ] bits of entropy of address space layout randomization for [selection: heap, stack, text] addresses. • The TSF shall generate [selection: stack, heap, other] protection cookies with [assignment: number of bits] bits of entropy.

27. Assumptions for usage • Like all security features these techniques can be used correctly and incorrectly • Several attacks and weaknesses discovered when techniques are used in a certain way • Assumptions would obviously need to be clearly defined within the Security Target

28. Conclusion • Common Criteria allows vendors to make claims regarding the security attributes of their products that can be independently verified • Common Criteria allows consumers to make an informed decision when comparing and selecting similar products • Address Space Integrity Protection Mechanisms are finding their way into commodity products • It is advantageous for both developers and consumers to have these features evaluated

29. White Paper • This presentation is based on a white paper produced within our Evaluation Lab • If you are interested come up and speak to me • Alternatively email me (address is on the next slide)

30. Questions, Comments, Thoughts, Suggestions? • Information on CSC Evaluations and Pre-Evaluation Consultation Services – aisef@csc.com • Feel free to email me – ashley.fox@csc.com • Thanks for listening!