1 / 24

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

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. Agenda. Introduction Approach to selecting Programming Languages Vulnerabilities

morag
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related