Security Code Review Using CAT.NET - Part 1

  • Article

Hi Andreas Fuchsberger here …

To coincide with the CTP release of CAT.NET and Anti-XSS, within the CSIG we have been taking a long hard look at static analysis tools for developers and Information Security professionals. Over the next series of blog posts I will explain the fundamentals of the techniques used for a code review in general and static code analysis in particular.

Today we start with an introduction into the review process and as well having a look at the techniques for automating some of the code review burden; and don't worry we will build up to the details fast.

In general we differentiate between a code review (source code) and an architectural review (software architecture). Although CAT.NET actually reads binary, actually Microsoft Intermediate Language code, it falls into the class of source code review tools.

What is a code review?

We say a code review is the process of systematically examining the source code written by one developer by someone other than the original developer, often called a reviewer. The reviewer could be a colleague or fellow developer or someone with similar developer background and skill set then we refer to this as a peer-review. Although most developers see the purpose of a code review to find coding errors the true value really lies really in the reviewer questioning assumptions by the original developer. It is often these unconsciously made assumptions that are the cause of business logic errors but also simple security errors (“Oh the user would never try to enter more than 10 digit telephone number”) .

Formal roots of the code review go as far back as 1983 when it was first mentioned in a standard, IEEE 729, although it is probably true to say that code reviews took place before using corporate or in-house rules.

According to the IEEE standard 729 “Glossary of Software Engineering Terminology”, which has since been republished as IEEE 610.12, a review is formally planned and structured analysis and evaluation process, during which the project results are presented to a team of consultant reviewers and commentated or approved by them.

The reviewer could be a fellow software developer. For inexperienced developers a code review offers a good opportunity to learn, for an experienced developer it offers the opportunity for training themselves in fast and hands-on manner.

And this unfortunately this is why the review process is so expensive both in cost of time and money. Reviewers are highly skilled people and performing a review takes time. So for some time now the Information Security research community has proposed automatic analysis techniques for identifying security vulnerabilities in code. Such techniques may employ dynamic analysis, static analysis, or both.

Dynamic analysis entails executing the program and inferring properties from its observed behaviour. Although dynamic analysis may expose bugs, it cannot ensure complete coverage of the target program as not all program paths may be actually run.

Instead, developers have adopted an approach based on sound analysis, which can provably identify all possible violations of specific security guidelines.

In contrast Static analysis does not execute the code but analyses the code itself. Simple static analysis tools analyses the actual source code, however increasingly modern static analysis tools use also or only look at the binary output of the compiler. For intermediate code output, such as Microsoft’s .NET Framework, this is in fact often preferable as the intermediate output still contains type information and

Static analysis techniques

There exist a number of static analysis techniques that can be used to automatically detect security errors in source code. These techniques cover three areas that have been associated with sources of security vulnerabilities:

  • Access control
  • Information flow
    • Integrity violations
    • Confidentiality violations
  • API conformance

Access control: Mechanisms for access control restrict access to security-sensitive resources based on a user's identity and/or membership in predefined groups. Ensuring that an access control policy enforces the required level of security can be difficult, especially for systems with many components of different trust levels with access to a multitude of restricted resources. If an access control policy does not grant sufficient permissions to users, runtime authorization failures will occur. On the other hand, if an access control policy grants users unnecessary permissions, this will result in exposing the exposing the system to security attacks.

Information flow: A secure information flow ensures that information propagates throughout the execution environment without violating two security integrity properties:

  • Integrity violations arise when untrusted information flows into a trusted execution environment without having been properly validated. A malicious user could compromise a system by exploiting an integrity violation.
  • Confidentiality violations arise when confidential information flows from a restricted execution environment to a public one without having been properly declassified. For example, a confidentiality violation arises if trusted code exposes a cryptographic private key to untrusted code.

API conformance: Applications often rely on libraries and third-party APIs to provide security-sensitive services. As an example, many applications rely heavily on cryptography libraries to protect confidentiality, prevent integrity violations, and distinguish between trusted and untrusted entities. Incorrect usage of cryptographic functions may lead to insecure storage of security-sensitive information and cause violations of integrity and confidentiality policies.

Our CAT.NET tool is based on finding integrity violations by performing a tainted data flow analysis. Future posting will take a closer look at the algorithms we used for performing our analysis.