DOC

Java Security

By Carmen Hunter,2014-04-24 11:40
16 views 0
Java Security

Whitepaper

Secure Programming in Java

(c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit

    Document History

Version-Date Editor Reviewer Status Remarks Number

    0.9 11/2005 EUROSEC DRAFT

    created by

    EUROSEC GmbH Chiffriertechnik & Sicherheit

    Sodener Straße 82 A, D-61476 Kronberg Germany

    www.eurosec.com mail: kontakt @ eurosec. com

    Phone: +49 (0) 6173 60850

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 2 of 27

    Table of Content

    1 Introduction ......................................................................................................................................................... 5 2 Security Mechanisms of the JRE ...................................................................................................................... 7 2.1 The execution of a Java program ? an overview ................................................................................. 7 2.1.1 Loading .................................................................................................................................................. 7 2.1.2 Linking ................................................................................................................................................... 8

    2.1.2.1 Verification .................................................................................................................................. 8

    2.1.2.2 Preparation .................................................................................................................................. 8

    2.1.2.3 Resolution .................................................................................................................................... 8 2.1.3 Initialization ........................................................................................................................................... 8 2.1.4 Security checks ...................................................................................................................................... 8 3 Secure Programming Guidelines .....................................................................................................................10 3.1 General Guidelines ..................................................................................................................................10 3.1.1 Coding style guidelines ......................................................................................................................10 3.1.2 Input data validation ..........................................................................................................................10 3.1.3 Performance optimization ................................................................................................................11 3.1.4 Assertions and debug traces .............................................................................................................11 3.1.5 Mutable objects ...................................................................................................................................12 3.1.6 Static variables .....................................................................................................................................13 3.1.7 Inheritance ...........................................................................................................................................13 3.1.8 Access of variables and methods .....................................................................................................13 3.2 Java specific Guidelines ..........................................................................................................................14 3.2.1 Garbage Collector ..............................................................................................................................14 3.2.2 Exceptions ...........................................................................................................................................14 3.2.3 Serialization and Deserialization ......................................................................................................15 3.2.4 Java Native Interface (JNI) ...............................................................................................................15 3.3 Security critical modules and tasks .......................................................................................................16 3.3.1 Separation of security critical modules............................................................................................16

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 3 of 27

     Cryptographic and security relevant packages ...............................................................................16 3.3.2

    3.3.3 Sensitive data .......................................................................................................................................17 3.3.4 Pseudo random data ..........................................................................................................................17 3.4 Java specific security mechanisms ........................................................................................................18 3.4.1 Bytecode verification .........................................................................................................................18 3.4.2 Policies and security managers .........................................................................................................18 3.4.3 Privileged code ....................................................................................................................................19 3.4.4 Packages ...............................................................................................................................................19 4 Resources ............................................................................................................................................................20 4.1 Research ....................................................................................................................................................20 4.1.1 SUN ......................................................................................................................................................20 4.1.2 IBM .......................................................................................................................................................21 4.1.3 Princeton University ? Secure Internet Programming project ...................................................21 4.2 Tools ..........................................................................................................................................................21 4.3 Books .........................................................................................................................................................23 4.3.1 Java Security ........................................................................................................................................23 4.3.2 Java virtual machine ...........................................................................................................................23 4.3.3 General Java programming guidelines ............................................................................................23 4.3.4 General secure programming guidelines.........................................................................................23 4.4 Java specifications....................................................................................................................................24 5 Appendix ? JRE 1.4.0 Security Providers .....................................................................................................25

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 4 of 27

    1 Introduction

    The Java programming language together with its runtime environment is well known to provide a lot of security features for applications written in Java and to the environment, in which Java applications are deployed. (In this paper, every kind of Java code running in some Java runtime environment, will be denoted as a Java application. In particular, applets are not distinguished from regular Java applications.) Indeed, under the often used slogan "Java Security", quite different aspects concerning the security of Java applications are addressed. First of all, to set?up the foundation for secure programs, Java has been designed to be an inherent safe programming language. In particular Java does not allow to directly access or manage memory. Furthermore, Java is strongly typed and elementary data types are definitely defined in the Java Language Specification

    [4.4 (1)]. Simply by its very basic language features, Java prevents a programmer from writing code that could produce buffer?overflows or overwrite data unintentionally. Errors that may

    occur from freeing memory are not possible, as such tasks are delegated to an automatic garbage collection mechanism. Moreover, as elementary data types are strictly defined, Java source code is compiler independent. Already at compile time, access to variables and methods can be checked and type checks are possible for widening casts of classes, interfaces and objects. Bytecode (class files) that has been generated by a correctly implemented Java compiler is therefore safe against its misuse to attack someone running such code in a (correctly implemented) runtime environment.

    When it comes to enforce security for a running application and its environment, the Java runtime environment (JRE) with its Java virtual machine (JVM) plays a major role. Its first duty is to check untrusted byte code (class files) for compliance with the Java virtual machine specification [4.4 (2)], a task that is not necessary for trusted code. These checks guarantee the protection against all sorts of attacks that might corrupt the memory of a process running untrusted bytecode. The JVM also complements the Java compiler with those checks that can only be performed at runtime, like boundary checks or type checks when applying narrowing cast operators. Finally the JRE allows the configuration and enforcement of detailed policies which encompass the exact permissions to be granted to a particular application for accessing system resources. When policies are configured it is possible to mandate that code has to be signed by an accepted authority in order to be granted specific permissions. Hence code signing (including the tools necessary to actually get some code signed) is another aspect of "Java Security".

    While not being part of the innermost security features, "Java Security" also encompasses some standard libraries and extensions that are shipped with SUN’s Java Development Kits (JDKs) and that are particularly aimed for the usage in security critical tasks. While the Java standard API does only define appropriate interfaces for most of these purposes , the JDKs also include implementations of cryptographic and security providers that might be used out of the box.

    As outlined above, the Java programming language provides a lot of security features, build directly into the language and also supplied by security relevant APIs and implementations. Nevertheless, simply by choosing Java as the programming language for some program, will not guarantee that the program will be safe against secrecy attacks, integrity or availability attacks. Security concerns should be considered throughout the whole software development process, independent of the particular programming language chosen.

    This paper discusses all the above mentioned aspects of "Java Security", but focuses on "secure programming" techniques that should be considered when programming in Java.

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 5 of 27

As "secure programming" is not possible without adhering to some general "good

programming" practices, some of the guidelines are therefore of a more general nature.

(c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 6 of 27

    2 Security Mechanisms of the JRE

    Java security relies heavily on the execution model as specified in the Java language

    specification [4.4 (1)] and in the Java virtual machine specification

    [4.4 (2)]. In particular it relies on bytecode verification, class loading mechanisms, security

    managers and access controllers. Before we are going to discuss secure programming

    guidelines in the following section, a short review of the execution model might be

    appropriate. Note: The Java security architecture has been improved considerably in JDK1.2

    compared to older JDK versions. This paper focuses on this improved architecture.

    2.1 The execution of a Java program ? an overview

    Chapter 12 of the Java language specification [4.4 (1)] specifies the activities that occur

    during the execution of a Java program. For execution of a Java program a Java virtual

    machine (JVM) has to be started with a class file that implements the main method of the

    program. At start?up the JVM holds no binary representation of the class containing the

    main method. Therefore the JVM invokes its class loader to try to load this class. After

    (successfully) loading the class it must be linked by the JVM. Linking comprises verification,

    preparation and (optionally) resolution. After the class has been linked, it will be initialized.

    As initialization of a class starts with the initialization of its super class, this step may involve

    (recursively) loading, linking and initializing further classes. Finally, after the class has been

    initialized, its main method is invoked. In case that unresolved references make their

    appearance in the execution thread(s), the corresponding classes have to be loaded, linked,

    and initialized, as well.

    2.1.1 Loading

    The method defineClass of the class ClassLoader is used to construct class objects from

    binary representations given in the class file format (bytecode). Well? behaved class loaders

    maintain the following properties [4.4 (1), 12.2]:

    ? Given the same name, a class loader should always return the same class object.

    ? If a class loader L1 delegates loading of a class C to another loader L2, then for any type

    T that occurs as the direct superclass or a direct superinterface of C, or as the type of a

    field in C, or as the type of a formal parameter of a method or constructor in C, or as a

    return type of a method in C, L1 and L2 should return the same class object.

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 7 of 27

2.1.2 Linking

    The specification allows an implementation of the JVM flexibility as to when linking

    activities (and, because of recursion, loading) take place, e.g.

    ? lazy (late) resolution: resolves symbolic references in a class/interface, only when it is

    used,

    ? static resolution: all references are resolved at once while the class is being verified. 2.1.2.1 Verification

    If the bytecode verifier detects a violation against the JVM specification, it throws an

    instance of VerifyError (subclass of LinkageError).

    2.1.2.2 Preparation

    During preparation the static fields (class variables and constants) for a class or interface are

    created and initialized to the default values. No source code has to be executed in this phase.

    (Additional data structures (such as a "method table") may be precomputed by the JVM

    (implementation dependent).)

    2.1.2.3 Resolution

    Symbolic references are checked to be correct and replaced with a direct reference that can

    be more efficiently processed.

    2.1.3 Initialization

    ? Initialization of a class: First its superclass is initialized (if not already done). Then the

    static initializers and the initializers for the static fields are executed.

    ? Initialization of an interface: The initializers for the fields are executed. Warning: It is

    possible to construct examples where the value of a class variable can be observed when

    it still has its initial default value, i.e. before its initializing expression is evaluated (see

    [4.4 (1), 12.4.1]).

    2.1.4 Security checks

    At runtime all security critical Java API methods call the check methods of the actually

    loaded SecurityManager class. Remember that by default SUN’s Java virtual machine does

    not initialize a SecurityManager object, i.e. an application is granted all permissions by default.

    To instantiate an object of the base SecurityManager class the option

    ?Djava.security.manager has to be used. The base SecurityManager class delegates most

    checks to the AccessController class of the JVM. The behavior of the AccessController class

    is configured at startup from policy files.

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 8 of 27

(c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 9 of 27

    3 Secure Programming Guidelines

    As mentioned in the introduction, secure programming is not possible without obeying some general good programming practices. Therefore this chapter is divided into two parts. The first part contains general rules that should be followed to write secure programs, while the second part concentrates on Java specific topics. Although the guidelines given in the first part are of a somewhat general nature and similar rules can be formulated for other programming languages as well, this paper concentrates on the specific implications for programming applications in Java.

    3.1 General Guidelines

    3.1.1 Coding style guidelines

    ? Establish and enforce company wide coding style guidelines. Having a well established software development process provides the necessary framework to produce robust, stable and secure software. Part of such a development process should be the implementation (and enforcement) of a set of coding style guidelines. Only if all software developers adhere to the same best programming practices, the final code will be in a consistent and simple state. This is the basis for maintainable and robust code, that can be evaluated (reviewed) and trusted to function as specified. Of course, experienced software engineers should be involved, when best practices are established.

    3.1.2 Input data validation

    ? Always validate input to public methods.

    Java is equipped with a lot of security features, such as automatic memory management, no pointer arithmetic and type safety. For that reason, programs written in Java are for example resistant against buffer overflow or format string attacks. Nevertheless, input validation for public methods is most important to guarantee a well defined behavior of a program. Parameters whose values are out of range should lead to cleanly flagged error states, which allows an application to fail securely. Moreover, input parameters may influence resources (e.g. memory consumption) or may be forwarded to native methods, making input validation even more important.

    ? Provide utility methods for input data validation and transformation purposes.

     (c) 2005, EUROSEC GmbH Chiffriertechnik & Sicherheit Page 10 of 27

Report this document

For any questions or suggestions please email
cust-service@docsford.com