CSCD 303 Essential Computer Security Spring 2013 Lecture 19 Creating Secure Programs

Overview Producing Secure Software Languages Libraries Tools Certifications Resources

Secure Languages Choosing the language is important for added software security Many of the most popular languages have known security problems Will look at C and Java

Do you trust your programming language? Modern programming platforms promise security: The Java security model is based on a customizable "sandbox" in which Java software programs can run safely, without potential risk to systems or users (java.sun.com/security) The .NET Common Language Runtime implements its own secure execution model that is independent of the host platform (Don Box, MSDN magazine) Most articles emphasise type-safety (=> memory safety) of the JVM or CLR And of course, special-purpose mechanisms such as Code Access Security (stack-walking), permissions, crypto, etc Look at what type-safe means

Secure programming platforms Java source C# C++ Visual Basic C++ compiler VB compiler Java compiler C# compiler JVML (bytecodes) CIL CIL CIL Executed on Executed on JVM (Java Virtual Machine) .NET CLR (Common Language Runtime) Queen Mary, University of London, May 2005

Non-safe Languages But one might ask: why is it bad to program in C and C++, anyway? What makes these languages unsafe, and what does that mean? Explore a few of C's unsafe features, and why programmers use them

Safe Languages In safe languages, values are managed "from the cradle to the grave": 1. Objects are created and initialized in a type-safe way 2. An object cannot be corrupted during its life time Its representation is in accordance with its type 3. Objects are destroyed, and their memory reclaimed, in a type-safe way

C Language Problems C does not have any of these protections: 1. C heap values are created in a type-unsafe way. 2. C casts, unchecked array accesses, and unsafe deallocation can corrupt memory during its lifetime. 3. C deallocation is unsafe, and can lead to dangling pointers.

C Language Problems Type-safe languages use some combination of static and dynamic checks to ensure that types cannot be violated No program can write an integer into a string location C is not a type-safe language, In C, any type can be viewed at any other type simply by using a cast: (type)expr

C Language Problems This operation causes expr to be treated as type, regardless of the type of expr. Unlike Java casts, C casts are not dynamically checked for "truthfulness" --- if the values are incompatible, compiler will "do the best it can", usually simply reinterpreting the in-memory bit pattern of expr as if it belonged to type.

Good techniques of Memory Management There are guarantees about dynamic memory allocation and deallocation: Allocation is type correct: One allocates memory of some given type; this memory is guaranteed to be of suitable size for its intended use. Allocation is private: This is a consequence of the above two points: No other part of the program possesses a pointer into freshly allocated data except the procedure that requested the allocation. Deallocation is safe: Garbage collector will not deallocate any data may be used again --- it only collects unreachable data.

Memory Management In garbage-collected languages, deallocation is implicit Programmer never explicitly tells the program to free the memory used by some object Good, because memory should only be reclaimed when it can never be used again, and programmers are not very good at figuring out by hand when memory can never be used again. Garbage collectors are better at this than humans: they only reclaim memory of objects they can prove will never be used. C is not garbage collected. It has a free function: int *i = (int*)malloc(sizeof(int)); free(i);

Problem of Dangling Pointer int *i = (int*)malloc(sizeof(int)); int j = 0; *i = 4; free(i); /* ... some code that might allocate memory, then: */ *i = j; /* Use deallocated memory. */ *i is referring to memory that has been deallocated When you deallocate memory, it goes back into pool from which malloc draws, so memory that i points to could have been reallocated and currently in use for some other purpose

C Array Bounds C does not have automatic array bounds checking Programmer must therefore check manually. that an index is within bounds before accessing array elements. Most C program security holes are "buffer overruns", cases when a program forgets to check some the bounds for some buffer (array) and overruns the end

The Java Solution Java Virtual Machine creates a sandbox Syntax - insecure operations cannot even be represented Automatic garbage collection prevents memory leaks Security Manager watches for anomalies during execution and can take action

JVM Java is an interpreted language Your source code is “compiled” to “bytecode” which is executed on the JVM (interpreted). The Java Virtual Machine (JVM) observes each instruction (bytecode) before it is used. This allows Java to provide the idea of a sandbox, which limits how an untrusted program can affect the system it runs on.

Java and the JVM The .class file contain Java Bytecode which is interpreted by the JVM (which is platform specific) File.java File.class Compiler javac File.class Java (JVM)

Language Level Security No pointers or pointer arithmetic No way to represent unstructured memory Variables, methods and classes can be final Compiler checks variable instantiation and typecasts

No Pointers Pointers and pointer arithmetic allow attackers to access any byte in memory In C, strings and arrays are essentially unstructured memory They start with a pointer and operations on array are done by manipulating pointer, no bounds checking Java programmer cannot represent or manipulate pointers

No Pointers You just can’t write a Java program to do damage like this. void main() { int *randAddress; randAddress = (int *) rand(); *randAddress = rand(); }

No Unstructured Memory Access Unstructured memory access (or unenforced structure) can be exploited. In C and C++, character data can be written to memory allocated as integer. Character or integer data can be read and interpreted as Boolean. Java prevents data of one type from being used as a different type – cannot be expressed in bytecode.

Source / Bytecode Produced public float add(float c, int d) { return c + d; } This will fail in Java if d was not an int, but a program in C assumes d is in the right format

Data Types Typesafe Language All memory and data types include format info A 2 byte integer takes up more than 2 bytes in memory – there is something to indicate that it is an integer so it can’t be used as something else.

Java Has some Problems Unspecified Memory Layout The JVM stores several types of data to execute a program Runtime stacks – one for each thread Bytecode for methods Dynamic memory heap and garbage collection area The storage layout is not defined for the JVM. Each implementation does it differently.

Java Has some Problems Other Sources of Error The bytecode instructions for array operations include bounds checking Branching instructions can only branch to instructions in the same method. Only return and invoke allow transfer of control outside a given method.

The Sandbox Idea The original Java release, jdk1.0, provided a system that used the basic sandbox model. Differentiated only between native code (code stored locally, trusted, given full access) and non-native code (applets downloaded, not trusted).

JDK 1.0 Sandbox Trusted code can read, write and delete any file, start and kill threads and open, use and close socket connections without any restrictions. Untrusted code cannot access any files, threads are hidden and only socket connections to the applet’s origin server are allowed.

JDK 1.1: More Flexible Native code is trusted and treated as in JDK1.0 Non-native code can be trusted or non-trusted. If the .jar file has a valid digital signature and comes from a “trusted developer” (list is part of the JVM) code is considered trusted and given same rights as native code. Otherwise, untrusted and restrictions apply.

JDK 1.2 ALL code (even native) is subject to a security policy that can be defined by the user. Permissions are checked against the policy when the class is loaded AND whenever restricted actions are attempted. Promotes Principle of Least Privilege Performs Complete Mediation

JDK 1.2 Restricted Actions Accept a socket connection Open a socket connection Wait for a connection on a port Create a new process Modify a thread Cause the application to exit Load a dynamic library that contains native methods Access or modify system properties Read from a file Write to a file Delete a file Create a new class loader Load a class from a specified package Add a new class to a specified package

However … In the Browser Can be unsave Recent … last two years, a number of exploits have bypassed Java security, DHS – said not to use Java Seems to be some exploits can bypass the Java Sandbox Polish security firm keeps finding zero day exploits http://blogs.computerworld.com/malware-and- vulnerabilities/21056/another-critical-java-vulnerability-puts-1-billion- users-risk

Safer Libraries

Prevention – Use better string libraries There is a choice between using statically vs dynamically allocated buffers Static approach easy to get wrong, and chopping user input may still have unwanted effects Dynamic approach susceptible to out-of-memory errors, and need for failing safely 33

Better String Libraries libsafe.h provides safer, modified versions of eg strcpy strlcpy(dst,src,size) and strlcat(dst,src,size) with size the size of dst, not the maximum length copied. Used in OpenBSD glib.h provides Gstring type for dynamically growing null-terminated strings in C But failure to allocate will result in crash that cannot be intercepted, which may not be acceptable Strsafe.h by Microsoft guarantees null-termination and always takes destination size as argument C++ string class Comparison of String Libraries http://www.and.org/vstr/comparison 34

Dynamic Countermeasures libsafe library prevents buffer overruns beyond current stack frame in the dangerous functions it redefines Dynamically loaded library. Intercepts calls to strcpy (dest, src) Validates sufficient space in current stack frame: |frame-pointer – dest| > strlen(src) If so, does strcpy. Otherwise, terminates application 35

Dynamic countermeasures libverify enhancement of libsafe keeps copies of the stack return address on the heap, and checks if these match 36

Purify A tool that developers and testers use to find memory leaks and access errors. Detects the following at the point of occurrence: Reads or writes to freed memory. Reads or writes beyond an array boundary. Reads from uninitialized memory. 37

Purify - Catching Array Bounds Violations http://en.wikipedia.org/wiki/IBM_Rational_Purify To catch array bounds violations, Purify allocates a small "red-zone" at the beginning and end of each block returned by malloc The bytes in the red-zone  recorded as unallocated If a program accesses these bytes, Purify signals an array bounds error Problem Does not check things on the stack Extremely expensive 38

Automated Tools Automated code review software checks source code for compliance with a predefined set of rules or best practices Use of analytical methods to inspect and review source code to detect bugs has been a standard development practice With automation, software tools provide assistance with the code review and inspection process Review program or tool typically displays a list of warnings A review program can also provide an automated or a programmer-assisted way to correct the issues found. http://en.wikipedia.org/wiki/Automated _code_review

Static Code Analysis Tools Strengths Scales Well - Can be run on lots of software, and can be repeatedly (like in nightly builds) For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.

Static Code Analysis Tools Weaknesses Many types of security vulnerabilities difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography Current state of art only allows such tools to automatically find small percentage of application security flaws … Tools of this type are getting better, however. * High numbers of false positives * Frequently can't find configuration issues, since they are not represented in the code. * Difficult to 'prove' that an identified security issue is an actual vulnerability. * Many tools have difficulty analyzing code that can't be compiled Analysts frequently can't compile code because they don't have right libraries, all the compilation instructions, all the code, etc.

Secure Code Certifications GIAC GSSP-Java http://www.giac.org/certification/secure-software- programmer-java-gssp-java CSSLP® - Certified Secure Software Lifecycle Professional https://www.isc2.org/CSSLP/Default.aspx Offensive Security OSCP Penetration Tester http://www.offensive-security.com/information-security- certifications/oscp-offensive-security-certified-professional/ GIAC Penetration Tester http://www.sans.org/press/giac_pentest_cert.php

References OWASP Static Analysis Paper Paper on Static Code Analysis https://www.owasp.org/index.php/Static_Code_Analysis Paper on Static Code Analysis http://msdn.microsoft.com/en-us/magazine/hh335064.aspx Notes on C's Unsafe Features http://www.cs.washington.edu/education/courses/cse341/04wi /lectures/26-unsafe-languages.html

End