12/13/04 Craig E. Ward, CMSI 601 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

12/13/04 Craig E. Ward, CMSI 601 2

Agenda Introduction Approach to selecting

Programming Languages Vulnerabilities

Four vulnerabilities will be presented Conclusions Questions and Comments

12/13/04 Craig E. Ward, CMSI 601 3

Programming Languages More than just one type Imperative Object-oriented Interpreted Virtual machine byte code Functional

12/13/04 Craig E. Ward, CMSI 601 4

Programming Languages

Language Version Platform

Java 1.4.2 Mac OS X

C GCC 3.3 Mac OS X, Cygwin

C++ GCC 3.3 Mac OS X

Perl 5.8 Mac OS X

Standard ML Moscow ML 2.01 Windows XP, Mac OS X

12/13/04 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

12/13/04 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.

12/13/04 Craig E. Ward, CMSI 601 7

General Vulnerabilities Malicious Input Race Conditions

12/13/04 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”

12/13/04 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

12/13/04 Craig E. Ward, CMSI 601 10

Overflow Vulnerabilities Integer Overflow Format String Vulnerabilities Stack Overflow Heap Overflow

12/13/04 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

12/13/04 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

12/13/04 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

12/13/04 Craig E. Ward, CMSI 601 14

Object Vulnerabilities Java Inner Classes Class compare by name

12/13/04 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

12/13/04 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;}

12/13/04 Craig E. Ward, CMSI 601 17

Java Inner ClassesCompiled 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();}

12/13/04 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?

12/13/04 Craig E. Ward, CMSI 601 19

Narrow Vulnerabilities Pointer Subterfuge Arc Injection C++ VPTR Exploit

12/13/04 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

12/13/04 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”

12/13/04 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

12/13/04 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

12/13/04 Craig E. Ward, CMSI 601 24

Questions or Comments?