The Phyla


The big list in this section takes the following form:

Kingdom

  • Phylum

<explanatory sentence or two>

I now introduce the phyla that fit under the seven (plus one) kingdoms. To better understand the relationship between kingdoms and phyla, consider a recently found vulnerability in Adobe Reader 5.0.x for UNIX. The vulnerability is present in a function UnixAppOpenFilePerform() that copies user-supplied data into a fixed-size stack buffer using a call to sprintf(). If the size of the user-supplied data is greater than the size of the buffer it is being copied into, important information, including the stack pointer, is overwritten. By supplying a malicious PDF document, an attacker can execute arbitrary commands on the target system.

The attack is possible because of a simple coding errorthe absence of a check that makes sure that the size of the user-supplied data is no greater than the size of the destination buffer. Developers will associate this check with a failure to code defensively around the call to sprintf(). I classify this coding error according to the attack it enables"Buffer Overflow." I chose Input Validation and Representation as the name of the kingdom the Buffer Overflow phylum belongs to because the lack of proper input validation is the root cause making the attack possible.

The coding errors represented by phyla can all be detected by static source code analysis tools. Source code analysis offers developers an opportunity to get quick feedback about the code they write. I strongly advocate educating developers about coding errors by having them use a source code analysis tool (see Chapter 4).

  1. Input Validation and Representation

    • Buffer Overflow

      Writing outside the bounds of allocated memory can corrupt data, crash the program, or cause the execution of an attack payload.

    • Command Injection

      Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.

    • Cross-Site Scripting

      Sending unvalidated data to a Web browser can result in the browser executing malicious code (usually scripts).

    • Format String

      Allowing an attacker to control a function's format string may result in a buffer overflow.

    • HTTP Response Splitting

      Writing unvalidated data into an HTTP header allows an attacker to specify the entirety of the HTTP response rendered by the browser.

    • Illegal Pointer Value

      This function can return a pointer to memory outside of the buffer to be searched. Subsequent operations on the pointer may have unintended consequences.

    • Integer Overflow

      Not accounting for integer overflow can result in logic errors or buffer overflows.

    • Log Forging

      Writing unvalidated user input into log files can allow an attacker to forge log entries or inject malicious content into logs.

    • Path Traversal

      Allowing user input to control paths used by the application may enable an attacker to access otherwise protected files.

    • Process Control

      Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.

    • Resource Injection

      Allowing user input to control resource identifiers may enable an attacker to access or modify otherwise protected system resources.

    • Setting Manipulation

      Allowing external control of system settings can disrupt service or cause an application to behave in unexpected ways.

    • SQL Injection

      Constructing a dynamic SQL statement with user input may allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.

    • String Termination Error

      Relying on proper string termination may result in a buffer overflow.

    • Struts: Duplicate Validation Forms

      Multiple validation forms with the same name indicate that validation logic is not up to date.

    • Struts: Erroneous validate() Method

      The validator form defines a validate() method but fails to call super.validate().

    • Struts: Form Bean Does Not Extend Validation Class

      All Struts forms should extend a Validator class.

    • Struts: Form Field without Validator

      Every field in a form should be validated in the corresponding validation form.

    • Struts: Plug-in Framework Not in Use

      Use the Struts Validator to prevent vulnerabilities that result from unchecked input.

    • Struts: Unused Validation Form

      An unused validation form indicates that validation logic is not up to date.

    • Struts: Unvalidated Action Form

      Every action form must have a corresponding validation form.

    • Struts: Validator Turned Off

      This action form mapping disables the form's validate() method.

    • Struts: Validator without Form Field

      Validation fields that do not appear in the forms they are associated with indicate that the validation logic is out of date.

    • Unsafe JNI

      Improper use of the Java Native Interface (JNI) can render Java applications vulnerable to security flaws in other languages. Language-based encapsulation is broken.

    • Unsafe Reflection

      An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.

    • XML Validation

      Failure to enable validation when parsing XML gives an attacker the opportunity to supply malicious input.

  2. API Abuse

    • Dangerous Function

      Functions that cannot be used safely should never be used.

    • Directory Restriction

      Improper use of the chroot() system call may allow attackers to escape a chroot jail.

    • Heap Inspection

      Do not use realloc() to resize buffers that store sensitive information.

    • J2EE Bad Practices: getConnection()

      The J2EE standard forbids the direct management of connections.

    • J2EE Bad Practices: Sockets

      Socket-based communication in Web applications is prone to error.

    • Often Misused: Authentication

      (See the complete entry on page 290 in this chapter.)

    • Often Misused: Exception Handling

      A dangerous function can throw an exception, potentially causing the program to crash.

    • Often Misused: Path Manipulation

      Passing an inadequately sized output buffer to a path manipulation function can result in a buffer overflow.

    • Often Misused: Privilege Management

      Failure to adhere to the principle of least privilege amplifies the risk posed by other vulnerabilities.

    • Often Misused: String Manipulation

      Functions that manipulate strings encourage buffer overflows.

    • Unchecked Return Value

      Ignoring a method's return value can cause the program to overlook unexpected states and conditions.

  3. Security Features

    • Insecure Randomness

      Standard pseudo-random number generators cannot withstand cryptographic attacks.

    • Least Privilege Violation

      The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.

    • Missing Access Control

      The program does not perform access control checks in a consistent manner across all potential execution paths.

    • Password Management

      Storing a password in plaintext may result in a system compromise.

    • Password Management: Empty Password in Configuration File

      Using an empty string as a password is insecure.

    • Password Management: Hard-Coded Password

      Hard-coded passwords may compromise system security in a way that cannot be easily remedied.

    • Password Management: Password in Configuration File

      Storing a password in a configuration file may result in system compromise.

    • Password Management: Weak Cryptography

      Obscuring a password with trivial encoding does not protect the password.

    • Privacy Violation

      Mishandling private information, such as customer passwords or social security numbers, can compromise user privacy and is often illegal.

  4. Time and State

    • Deadlock

      Inconsistent locking discipline can lead to deadlock.

    • Failure to Begin a New Session upon Authentication

      Using the same session identifier across an authentication boundary allows an attacker to hijack authenticated sessions.

    • File Access Race Condition: TOCTOU

      The window of time between when a file property is checked and when the file is used can be exploited to launch a privilege escalation attack.

    • Insecure Temporary File

      Creating and using insecure temporary files can leave application and system data vulnerable to attack.

    • J2EE Bad Practices: System.exit()

      A Web application should not attempt to shut down its container.

    • J2EE Bad Practices: Threads

      Thread management in a Web application is forbidden in some circumstances and is always highly error prone.

    • Signal Handling Race Conditions

      Signal handlers may change shared state relied on by other signal handlers or application code causing unexpected behavior.

  5. Error Handling

    • Catch NullPointerException

      Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.

    • Empty Catch Block

      Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

    • Overly Broad Catch Block

      Catching overly broad exceptions promotes complex error-handling code that is more likely to contain security vulnerabilities.

    • Overly Broad Throws Declaration

      Throwing overly broad exceptions promotes complex error-handling code that is more likely to contain security vulnerabilities.

    • Unchecked Return Value

      Ignoring a method's return value can cause the program to overlook unexpected states and conditions.

  6. Code Quality

    • Double Free

      Calling free() twice on the same memory address can lead to a buffer overflow.

    • Inconsistent Implementations

      Functions with inconsistent implementations across operating systems and operating system versions cause portability problems.

    • Memory Leak

      Memory is allocated but never freed, leading to resource exhaustion.

    • Null Dereference

      The program can potentially dereference a null pointer, thereby raising a NullPointerException.

    • Obsolete

      The use of deprecated or obsolete functions may indicate neglected code.

    • Undefined Behavior

      The behavior of this function is undefined unless its control parameter is set to a specific value.

    • Uninitialized Variable

      The program can potentially use a variable before it has been initialized.

    • Unreleased Resource

      The program can potentially fail to release a system resource.

    • Use After Free

      Referencing memory after it has been freed can cause a program to crash.

  7. Encapsulation

    • Comparing Classes by Name

      Comparing classes by name can lead a program to treat two classes as the same when they actually differ.

    • Data Leaking Between Users

      Data can "bleed" from one session to another through member variables of singleton objects, such as servlets, and objects from a shared pool.

    • Leftover Debug Code

      Debug code can create unintended entry points in an application.

    • Mobile Code: Object Hijack

      Attackers can use cloneable objects to create new instances of an object without calling its constructor.

    • Mobile Code: Use of Inner Class

      Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.

    • Mobile Code: Non-Final Public Field

      Non-final public variables can be manipulated by an attacker to inject malicious values.

    • Private Array-Typed Field Returned from a Public Method

      The contents of a private array may be altered unexpectedly through a reference returned from a public method.

    • Public Data Assigned to Private Array-Typed Field

      Assigning public data to a private array is equivalent to giving public access to the array.

    • System Information Leak

      Revealing system data or debugging information helps an adversary learn about the system and form an attack plan.

    • Trust Boundary Violation

      Commingling trusted and untrusted data in the same data structure encourages programmers to mistakenly trust unvalidated data.

  • Environment

    • ASP .NET Misconfiguration: Creating Debug Binary

      Debugging messages help attackers learn about the system and plan a form of attack.

    • ASP .NET Misconfiguration: Missing Custom Error Handling

      An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.

    • ASP .NET Misconfiguration: Password in Configuration File

      Do not hardwire passwords into your software.

    • Insecure Compiler Optimization

      Improperly scrubbing sensitive data from memory can compromise security.

    • J2EE Misconfiguration: Insecure Transport

      The application configuration should ensure that SSL is used for all access-controlled pages.

    • J2EE Misconfiguration: Insufficient Session-ID Length

      Session identifiers should be at least 128 bits long to prevent brute-force session guessing.

    • J2EE Misconfiguration: Missing Error Handling

      A Web application must define a default error page for 404 errors and 500 errors and to catch java. lang. Throwable exceptions to prevent attackers from mining information from the application container's built-in error response.

    • J2EE Misconfiguration: Unsafe Bean Declaration

      Entity beans should not be declared remote.

    • J2EE Misconfiguration: Weak Access Permissions

      Permission to invoke EJB methods should not be granted to the ANYONE role.

More Phyla Needed

This taxonomy includes coding errors that occur in a variety of programming languages. The most important among them are C and C++, Java, and the .NET family (including C# and ASP). Some of the phyla are language-specific because the types of errors they represent apply only to specific languages. One example is the Double Free phylum. This phylum identifies incorrect usage of low-level memory routines and is specific to C and C++ because neither Java nor the managed portions of the .NET languages expose low-level memory APIs.

In addition to being language-specific, some phyla are framework-specific. For example, the Struts phyla apply only to the Struts framework, and the J2EE phyla are only applicable in the context of the J2EE applications. Log Forging, on the other hand, is a more general phylum.

The phylum list as it exists is certainly incomplete, but it is adaptable to changes in trends and discoveries of new defects that are bound to happen over time. The current list reflects a focus on finding and classifying security-related defects rather than more general quality or reliability issues. The Code Quality kingdom could potentially contain many more phyla, but the ones that are currently included are the most likely to affect software security directly. Finally, classifying errors that are most important to real-world enterprise developers is the most important goal of this taxonomymost of the information here is derived from the literature, various colleagues, and hundreds of customers.




Software Security. Building Security In
Software Security: Building Security In
ISBN: 0321356705
EAN: 2147483647
Year: 2004
Pages: 154
Authors: Gary McGraw

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net