Implications of Programming Language Selection on the Construction of Secure Software Systems

1. Implications of Programming Language Selection on the Construction of Secure Software Systems A presentation of the paper for CMSI 601 Graduate Seminar, Loyola Marymount University Craig E. Ward, CMSI 601

2. Agenda • Introduction • Approach to selecting • Programming Languages • Vulnerabilities • Four vulnerabilities will be presented • Conclusions • Questions and Comments Craig E. Ward, CMSI 601

3. Programming Languages • More than just one type • Imperative • Object-oriented • Interpreted • Virtual machine byte code • Functional Craig E. Ward, CMSI 601

4. Programming Languages Craig E. Ward, CMSI 601

5. Vulnerabilities • Range from general to specific • General vulnerabilities that present problems for all programming languages • Vulnerabilities that present risks to just a particular programming language • Vulnerabilities that effect particular implementation of a programming language Craig E. Ward, CMSI 601

6. Vulnerabilities • List a group of similar vulnerabilities • Use one to illustrate the group • Some vulnerabilities could fit into more-than-one group so these groupings are not absolute. Craig E. Ward, CMSI 601

7. General Vulnerabilities • Malicious Input • Race Conditions Craig E. Ward, CMSI 601

8. Malicious Input • Programs that blindly accept input from external sources are vulnerable to exploits • Especially problematic if this input is executed • Input should be sanitized using a “white list” Craig E. Ward, CMSI 601

9. Malicious Input • C (and C++) • The library routine system() is dangerous • Java • Runtime.exec() almost as dangerous • Perl • Some protection with taint mode (if you turn it on) • ML • OS.Process.system() is dangerous too Craig E. Ward, CMSI 601

10. Overflow Vulnerabilities • Integer Overflow • Format String Vulnerabilities • Stack Overflow • Heap Overflow Craig E. Ward, CMSI 601

11. Integer Overflow • Attempting to store an integer larger than will fit in the allocated space • Most overflows wrap; some saturate • Can be used to break protections around “bad” C library routines Craig E. Ward, CMSI 601

12. Integer Overflow • C/C++ • Loss of precision from automatic conversions • Overflow from calculation • Change of sign • Java • Signed only • Compiler prevents loss of precision from assignments Craig E. Ward, CMSI 601

13. Integer Overflow • Perl • Scalars interpreted at runtime as integer, float, string • ML • No automatic conversions or casts • Throws exception on overflow Craig E. Ward, CMSI 601

14. Object Vulnerabilities • Java Inner Classes • Class compare by name Craig E. Ward, CMSI 601

15. Java Inner Classes • Nested classes given access to outer class members • JVM does not recognize a difference between regular and inner classes • To give appearance of access by inner classes, accessed members given package scope Craig E. Ward, CMSI 601

16. Java Inner Classes public class Flag { class InnerFlag { public void incFlag() { flag++; } public void showFlag() { System.out.println("The hidden flag is " + flag); } } public Flag(int flag) { this.flag = flag * 5; } private int flag; } Craig E. Ward, CMSI 601

17. Java Inner Classes Compiled from "Flag.java" public class Flag extends java.lang.Object{ private int flag; public Flag(int); static int access$008(Flag); static int access$000(Flag); } Compiled from "Flag.java" class Flag$InnerFlag extends java.lang.Object{ private final Flag this$0; Flag$InnerFlag(Flag); public void incFlag(); public void showFlag(); } Craig E. Ward, CMSI 601

18. Java Inner Classes • C++ does not automatically give nested classes access to outer class • Perl does not enforce any encapsulation • Everyone expected to play nice • ML does not have inner classes or notion of “friend” class. Uses signatures. • Is Java wrong for being orthogonal? Craig E. Ward, CMSI 601

19. Narrow Vulnerabilities • Pointer Subterfuge • Arc Injection • C++ VPTR Exploit Craig E. Ward, CMSI 601

20. Pointer Subterfuge • A counterattack to preventative measures on some Unix systems • Exploit targets Linux on IA32 • StackGuard canary before return address • If stack overwritten, canary would change • StackShield return address stack • If return address different from saved, abort Craig E. Ward, CMSI 601

21. Pointer Subterfuge • Characteristics of a “protected” program that cause protection to fail: • A pointer located next to a buffer • A misused library routine that can overflow into the pointer • A second copy that uses the pointer without the pointer being initialized • “wu-ftpd 2.5 mapped_path bug” Craig E. Ward, CMSI 601

22. Pointer Subterfuge • Use the overflowed pointer to change the return address without damaging the canary • Use the overflowed pointer to change list of exit routines to trick StackShield • Use the overflowed pointer to change address of copy function to system Craig E. Ward, CMSI 601

23. Conclusions • Security is important and must be considered when choosing a programming language. Speed isn’t everything. • No programming language is completely safe • Object orientation only minimally helps • Functional programming may help • Use static analysis tools designed for the language you are using Craig E. Ward, CMSI 601

24. Questions or Comments? Craig E. Ward, CMSI 601