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

2. Overview Producing Secure Software Languages Libraries Tools
Certifications
Resources

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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.

9. 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

10. 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.

11. 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.

12. 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);

13. 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

14. 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

15. 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

16. 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.

17. 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)

18. 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

19. 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

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

21. 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.

22. 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

23. 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.

24. 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.

25. 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.

26. 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).

27. 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.

28. 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.

29. 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

30. 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

31. 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
vulnerabilities/21056/another-critical-java-vulnerability-puts-1-billion- users-risk

32. Safer Libraries

33. 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

34. 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 34

35. 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

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

37. 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

38. Purify - Catching Array Bounds Violations
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

39. 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.
_code_review

40. 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.

41. 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.

42. Secure Code Certifications
GIAC GSSP-Java
programmer-java-gssp-java
CSSLP® - Certified Secure Software Lifecycle Professional
Offensive Security OSCP Penetration Tester
certifications/oscp-offensive-security-certified-professional/
GIAC Penetration Tester

43. References OWASP Static Analysis Paper Paper on Static Code Analysis
Paper on Static Code Analysis
Notes on C's Unsafe Features
/lectures/26-unsafe-languages.html

44. End