Secure Coding in Java and .NET

1. Secure Coding inJava and .NET Part 1: Fundamentals

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

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

4. Use of Intermediate Languages • Compilers target intermediate language rather than native machine code • Java → bytecode • C#, VB.NET, etc → CIL (‘managed code’) • 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 SY32 Secure Computing, Lecture 16

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

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

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

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

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

10. 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? SY32 Secure Computing, Lecture 16

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

12. Example • 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 • Bona fide compiler will refuse to compile this type confusion attack… • …but what if attacker writes in CIL? SY32 Secure Computing, Lecture 16

13. 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 SY32 Secure Computing, Lecture 16

14. .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! SY32 Secure Computing, Lecture 16

15. Explanation • 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 • Exact behaviour depends on how code access security policy has been configured SY32 Secure Computing, Lecture 16

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

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

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

19. .NET 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 • Each application domain can be programmed with its own code access security policy SY32 Secure Computing, Lecture 16

20. .NET Isolated Storage • 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 • Virtual filesystem; no way of specifying a path to another store or rest of disk • Quotas can be imposed to prevent DoS SY32 Secure Computing, Lecture 16

21. Code Signing • 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 • Java supports signing of JAR files • .NET supports signing of assemblies • To guarantee integrity & uniqueness (strong naming) • To identify publisher (Authenticode) SY32 Secure Computing, Lecture 16

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

23. Signature Verification Process JAR Bytecode New hash Comparehashes Checksignature Signed hash Originalhash Signer'spublic key SY32 Secure Computing, Lecture 16

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