2–6 Mar 2009
Le Ciminiere, Catania, Sicily, Italy
Europe/Rome timezone

Session

Vulnerability Assessment and Secure Coding Practices for Middleware Tutorial

2 Mar 2009, 09:00
Le Ciminiere, Catania, Sicily, Italy

Le Ciminiere, Catania, Sicily, Italy

Viale Africa 95100 Catania

Description

Vulnerability Assessment and Secure Coding Practices for Middleware Tutorial (1/2) (90 mins)
James A. Kupsch and Prof. Barton P. Miller

Security is crucial in the software that we develop and use. This tutorial is relevant to anyone wanting to learn about assessing software for security flaws and for developers wishing to minimize security flaws in software they develop.

We share our experience in vulnerability assessment of real-world grid middleware. You will learn skills critical for developers and analysts concerned about software security, and the importance of independent vulnerability assessment.

The tutorial covers a process to actively discover vulnerabilities. We show how to gather information about a system which is used to direct the search for vulnerabilities, and how to integrate vulnerability assessment and discovery into the development cycle.

Next, we examine coding practices to prevent vulnerabilities by describing more than 20 types of vulnerabilities with examples of how they commonly arise, and techniques to prevent them. Most examples are in C, C++, Perl, and the standard C and POSIX APIs.

This tutorial teaches critical assessment and coding skills. In addition, it discusses policy issues relating to independent auditing, vulnerability reporting, and integrating security fixes into the software release cycle.
The security of software is becoming increasingly important to anyone who uses or develops it. This tutorial teaches developers and assessors how to proactively reduce the number of vulnerabilities in their software. Just as independent QA testing is essential for assessing software reliability, testing for security is essential for assuring software security. Even projects that architect their software with security in mind still need independent vulnerability assessment to detect design flaws or coding problems that can arise in any project. Testing for security is an essential part of the development process and a unique skill that requires training.

This tutorial is an outgrowth of our experience in performing vulnerability assessment of a variety of grid middleware, which includes Condor from the University of Wisconsin, the Storage Resource Broker from the San Diego Supercomputer Center, MyProxy from the National Center for Supercomputer Applications, and EGEE's glexec. The tutorial teaches the processes and skills that we developed and used in these activities.

This tutorial is relevant to anyone who wants to learn about analyzing software for security flaws and for developers wishing to minimize security flaws in software that they develop. It covers the two sides of security: the offensive--how to find problems through the use of proactive vulnerability assessment; and the defensive--how to prevent problems by showing many types of vulnerabilities that occur in code and what techniques can be used to prevent them.

The target audience for this tutorial is anyone involved with the development of software, wishing to assess the security of software, or managing the software development process. To gain maximum benefit from this tutorial, attendees should be familiar with the process of developing software and the C programming language, along with a basic knowledge of the standard C library and the POSIX API.

This tutorial does not assume any prior knowledge of security assessment or vulnerabilities. Some of the examples include less common APIs, or are in a programming language other than the C programming language. In these instances, enough explanation is given so the attendee unfamiliar with the topic should be able to understand the concepts.

The first part of this tutorial explains how to perform a vulnerability assessment. Our process is based on a deep assessment of the software, done by one who is working in cooperation with the development team and has access to source code, internal documents and developers. We emphasize understanding of the process of vulnerability assessment and developing the skills needed to conduct such an assessment.

The first step of a vulnerability assessment is to gain an in-depth understanding of the system. Without an understanding of how it works, it is impossible to know what are the critical assets and what are the threats to these assets. To do this, the tutorial shows a process to gather and document this information by performing an architectural, resource and privilege analysis. These steps are completed by meeting with the developers, reviewing design documents and end-user documentation, using the system, and looking at the code.

The architectural analysis consists of discovering and documenting the high level structures of the system: functionality, hosts, configuration parameters, processes, user interaction, interactions between processes, interactions with external systems, other communication channels, resources controlled by processes, and trust between components.

The resource and privilege analysis is the process of discovering and documenting the objects that the system can manipulate, such as in-memory data structures, database records, files, CPU cycles, and physical devices controlled by the computer. It also documents what actions can be performed on the resources in the system. The privilege analysis documents the privilege model defined by the system itself, and the configuration of privileges in the underlying operating system and external applications, such as databases.

The tutorial then shows how to create data flow diagrams from the results of the prior analyses. These diagrams contain much of the information collected earlier in a succinct fashion that allows the analyst to easily comprehend the system.

The tutorial then covers the process of performing a component analysis, which is looking for vulnerabilities in components of the system. Since it is not realistic to completely verify the security of the system, the tutorial shows how to use the previous steps of the analysis to focus the search to find both those that are likely to be easily found by outside attackers, and also those vulnerabilities that can lead to higher value targets such as the compromise of the host operating system or a subversion of the privilege system. Information in the second part of the tutorial explains how to look for specific types of vulnerabilities.

The tutorial also describes how to integrate the results of the vulnerability assessment process into the software development process, including writing vulnerability reports, the vulnerability disclosure process, fixing vulnerabilities, and releasing security updates.

The second part of this tutorial focuses on vulnerabilities. It features several interactive secure coding quizzes where the audience is challenged to find as many vulnerabilities as they can in short code fragments. What the audience finds (and does not find) are then discussed.

This part also contains a discussion of the most common vulnerabilities and is valuable to both developers and security assessors. Descriptions of each vulnerability are presented with examples. It is shown how the vulnerability typically occurs within code, pointing out APIs or techniques that commonly result in the vulnerability, and also how the vulnerability can be mitigated or eliminated through the use of other techniques or APIs. The causes and types of vulnerabilities covered include:

  • Lack of data validation
  • Error Handling
  • Buffer overflows
  • Numeric parsing
  • Integer vulnerabilities
  • Race conditions
  • Injection attacks
  • Format string attack
  • Command injection
  • SQL injection
  • Cross-site scripting (XSS)
  • Directory traversals
  • Memory management attacks
  • Race conditions
  • Denial of service
  • Insecure permissions
  • Not dropping privileges
  • Information leaks

Presentation materials

There are no materials yet.
Building timetable...