© 2003 School of Computing, University of Leeds SY32 Secure Computing, Lecture 16 Secure Coding in Java and.NET Part 1: Fundamentals

2 SY32 Secure Computing, Lecture 16 Outline Basic security features of Java and.NET Basic security features of Java and.NET Use of intermediate languages Use of intermediate languages Validation and verification of IL code Validation and verification of IL code Restricted execution environments Restricted execution environments Code signing Code signing

3 SY32 Secure Computing, Lecture 16 Basic Security Features Well-defined, standardized type system Well-defined, standardized type system Strict compile-time type checking Strict compile-time type checking Lack of pointer arithmetic Lack of pointer arithmetic Garbage collection Garbage collection Bounds checking of arrays, etc Bounds checking of arrays, etc No buffer overruns! No buffer overruns!

4 SY32 Secure Computing, Lecture 16 Use of Intermediate Languages Compilers target intermediate language rather than native machine code Compilers target intermediate language rather than native machine code Java bytecode Java bytecode C#, VB.NET, etc CIL (managed code) C#, VB.NET, etc CIL (managed code) Intermediate code is typically JIT-compiled to native code by a virtual machine (VM) Intermediate code is typically JIT-compiled to native code by a virtual machine (VM) VM can perform various security checks when loading, JIT-compiling or running code VM can perform various security checks when loading, JIT-compiling or running code

5 SY32 Secure Computing, Lecture 16 Java Bytecode Internet Bytecode JVM Verifier Class loader Class object Class loader Disk Original Java model (SDK 1.0 & 1.1) Bytecode

6 SY32 Secure Computing, Lecture 16 Java Bytecode Internet Bytecode JVM Verifier Class loader Class object Class loader Disk Java 2 model (SDK 1.2 & above) Core API bytecode Disk Bytecode

7 SY32 Secure Computing, Lecture 16 Class Loaders & Security Bytecode with different origins is loaded by different class loader objects Bytecode with different origins is loaded by different class loader objects JVM identifies a class by name and class loader JVM identifies a class by name and class loader Prevents, e.g., hostile applet from substituting its java.net.Socket class for real one Prevents, e.g., hostile applet from substituting its java.net.Socket class for real one Difficult to implement correctly; bugs found in Difficult to implement correctly; bugs found in March & May 1996 March & May 1996 July 1998 July 1998 November 2000 November 2000

8 SY32 Secure Computing, Lecture 16 Bytecode Verification Verifier looks for Verifier looks for.class file format violations.class file format violations Abuse of final modifier Abuse of final modifier Classes that don't have one superclass Classes that don't have one superclass Illegal data conversions Illegal data conversions Operand stack overflow or underflow Operand stack overflow or underflow Field and method access checking is delayed until runtime, then performed once only Field and method access checking is delayed until runtime, then performed once only

9 SY32 Secure Computing, Lecture 16 Code Validation in.NET Managed code is organized as logical units called assemblies, containing CIL instructions, metadata and resources Managed code is organized as logical units called assemblies, containing CIL instructions, metadata and resources Validation checks that Validation checks that Files have correct format (PE/COFF) Files have correct format (PE/COFF) Metadata are present and uncorrupted Metadata are present and uncorrupted CIL instructions are legal CIL instructions are legal

10 SY32 Secure Computing, Lecture 16 Example.method static void Main() cil managed {.entrypoint.maxstack 2 ldc.i4.1 add ldstr "1 + 2 = " call void [mscorlib]System.Console::Write(string) call void [mscorlib]System.Console::WriteLine(int32) ret } ldc.i4.2 What happens when ldc.i4.2 instruction is removed?

11 SY32 Secure Computing, Lecture 16 Code Verification in.NET Verification checks type safety of CIL code Verification checks type safety of CIL code Algorithm will reject some type-safe code Algorithm will reject some type-safe code Failure doesn't necessarily prevent execution Failure doesn't necessarily prevent execution Type-safe code Verifiable code All code

12 SY32 Secure Computing, Lecture 16 Example C# class Secret contains a private integer field C# class Secret contains a private integer field Attacker writes a class Hack with a public integer field, then attempts to make a Hack reference point to a Secret instance Attacker writes a class Hack with a public integer field, then attempts to make a Hack reference point to a Secret instance Bona fide compiler will refuse to compile this type confusion attack… Bona fide compiler will refuse to compile this type confusion attack… …but what if attacker writes in CIL? …but what if attacker writes in CIL?

13 SY32 Secure Computing, Lecture 16 class Secret { private int data;... } class Hack { public int data; static void Main() { Secret s = new Secret(); Hack h = new Hack(); h = s; System.Console.WriteLine(h.data); } } compiler error

14 SY32 Secure Computing, Lecture 16.field public int32 'data'.method static void Main() cil managed {.entrypoint.maxstack 2.locals init (class [Secret]Secret V_0, class Hack V_1) newobj instance void [Secret]Secret::.ctor() stloc.0 newobj instance void Hack::.ctor() stloc.1 ldloc.0 stloc.1 ldloc.1 ldfld int32 Hack::'data' call void [mscorlib]System.Console::WriteLine(int32) ret } type confusion… …but this code might execute, nevertheless!

15 SY32 Secure Computing, Lecture 16 Explanation Assembly that fails verification may run if loaded from local disk, because such code is trusted fully by default Assembly that fails verification may run if loaded from local disk, because such code is trusted fully by default Same assembly downloaded from a web server will normally not be executed Same assembly downloaded from a web server will normally not be executed Exact behaviour depends on how code access security policy has been configured Exact behaviour depends on how code access security policy has been configured

16 SY32 Secure Computing, Lecture 16 Problems IL verification is hard to implement correctly IL verification is hard to implement correctly Example: bugs in Java's bytecode verifier Example: bugs in Java's bytecode verifier March 1996 March 1996 March & May 1997 March & May 1997 April 1999 April 1999 March 2002 March 2002 January 2003 January 2003

17 SY32 Secure Computing, Lecture 16 Restricted Environments The Java sandbox The Java sandbox.NET application domains.NET application domains.NET isolated storage.NET isolated storage

18 SY32 Secure Computing, Lecture 16 The Classic Java Sandbox Applets from the Internet are not trusted and must execute in a sandbox Applets from the Internet are not trusted and must execute in a sandbox Cannot run programs on client machine Cannot run programs on client machine No access to local file system No access to local file system Network access restricted to originating site Network access restricted to originating site Applications from local disk are implicitly trusted and have full privileges of executing user Applications from local disk are implicitly trusted and have full privileges of executing user Restrictive, black and white security model, improved in later versions Restrictive, black and white security model, improved in later versions

19 SY32 Secure Computing, Lecture 16.NET Application Domains Assemblies of a.NET application can be loaded into different application domains Assemblies of a.NET application can be loaded into different application domains Application domains are isolated from each other, communicating only via remoting Application domains are isolated from each other, communicating only via remoting Each application domain can be programmed with its own code access security policy Each application domain can be programmed with its own code access security policy

20 SY32 Secure Computing, Lecture 16.NET Isolated Storage Applications may need to have some persistent state, but granting unrestricted access to hard disk is risky Applications may need to have some persistent state, but granting unrestricted access to hard disk is risky Isolated storage provides areas of disk that are private to a given user & assembly Isolated storage provides areas of disk that are private to a given user & assembly Virtual filesystem; no way of specifying a path to another store or rest of disk Virtual filesystem; no way of specifying a path to another store or rest of disk Quotas can be imposed to prevent DoS Quotas can be imposed to prevent DoS

21 SY32 Secure Computing, Lecture 16 Code Signing IL code can be signed digitally by someone prepared to vouch for that code IL code can be signed digitally by someone prepared to vouch for that code If signature can be verified, code may be regarded as trusted, and be granted greater privileges If signature can be verified, code may be regarded as trusted, and be granted greater privileges Java supports signing of JAR files Java supports signing of JAR files.NET supports signing of assemblies.NET supports signing of assemblies To guarantee integrity & uniqueness (strong naming) To guarantee integrity & uniqueness (strong naming) To identify publisher (Authenticode) To identify publisher (Authenticode)

22 SY32 Secure Computing, Lecture 16 JAR Signing Process Bytecode Signed hash Hash Bytecode Signed hash Signer's private key

23 SY32 Secure Computing, Lecture 16 Signature Verification Process JAR Bytecode Signed hash Original hash New hash Check signature Compare hashes Signer's public key

24 SY32 Secure Computing, Lecture 16 Summary Java and.NET promote greater security in development and in code execution Java and.NET promote greater security in development and in code execution Correctness of compiled code can be verified before it executes Correctness of compiled code can be verified before it executes Implementations are not perfect Implementations are not perfect Some system configuration may be required Some system configuration may be required Java and.NET restrict access that untrusted code has to other code, filesystem, network, etc Java and.NET restrict access that untrusted code has to other code, filesystem, network, etc Restrictions can be relaxed for signed code Restrictions can be relaxed for signed code