CSC/ECE 517 Fall 2010/ch4 4h sk: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 18: Line 18:


===How do Static Code Analysis Tools Identify Problems Quickly?===
===How do Static Code Analysis Tools Identify Problems Quickly?===
:First and foremost static analysis tools are efficient to use because they don't actually execute the code. These tools actually use what are known as static checkers which construct an abstract model of the code base and then travel through the program looking for patterns and common traps developers typically perform. Some of the most common and most useful criteria these static checkers use on this abstract model of the code base are:
:*'''Null Returns''' - Check to see if functions can return unexpected NULLs and create a segmentation fault
:*'''Forward Null''' - Check to see what paths generate a NULL pointer de-reference and create denial of service risks
:*'''Reverse Null''' - Check to see if pointers are checked against NULL before being de-referenced
:*'''Reverse Negative''' - Check to see if negative values are used in inappropriate places that open the program to security risk
:*'''Sizecheck''' - Check to see if correct memory allocation is used to prevent memory out of bounds errors
:*'''Resource Leak''' - Check to see if memory leaks exist that can introduce performance and crash problems
:*'''Use After Free''' - Check to see if once resources have been de-allocated from a heap, that these are not used again as they may cause nondeterministic results
:*'''Uninit''' Check to see if variables are initialized before use
:*'''Overrun Static''' - Check to see if there are invalid accesses to a static array which may lead to buffer overrun security risks
:*'''Overrun Dynamic''' - Check to see if there are invalid accesses to a dynamic array which may lead to buffer overrun security risks
:*'''Negative Returns''' - Check to see if a function returns a negative value that is returned inappropriately which may lead to memory corruption, crashes, infinite loops, etc.
===Is Static Code Analysis Important?===
===Is Static Code Analysis Important?===
===Are There Drawbacks to Using Static Code Analysis?===
===Are There Drawbacks to Using Static Code Analysis?===

Revision as of 19:25, 19 October 2010

What is Static Code Analysis?

If there is one thing that has proven to be true over time is is that humans are fallible. We by nature, make mistakes. As a result, our humanity must be factored in to the software engineering and development that we produce. Development teams discovered early on that code review was the best way to discover mistakes and bugs in their software. This proved to be a daunting task however. Assembling teams to identify problems in the code base as well as training them took up large amounts of time and valuable resources. Obviously code review and bug discovery were critical areas of software development that needed to be addressed, but development teams needed a more efficient way to go about doing it.
In the 1970's Stephen Johnson at Bell Laboratories wrote a program call Lint. Lint's functionality was to look at C programs that had made it through compilation without any errors and examine the source code to locate any bugs that were not detected. With this, static code analysis was born.
Static code analysis defines tools used to verify the quality and reliability of software systems quickly and efficiently. There are many static code analysis tools out there for many different languages. Some of these are open source products and some are commercially based. Their scope and accuracy can vary quite a bit depending on what tool a development team uses. There are some traits of these tools that are for the most part universal however.

How do Static Code Analysis Tools Identify Problems?

While humans are fallible, at least we tend to be consistent about it. No matter the company or region of the world, software developers tend to fall into the same traps over and over. This creates patterns and known high risk situation that can be identified through programmatic means. Key aspects of a program that pretty much all static code analysis tool focus on are:
  • Input validation and representation - Based on different key combinations and encoding of alphanumeric characters, what user flows put the code at risk to attack.
  • API abuse - Does the caller violate the API terms
  • Security features - Are the security steps taken legal. Is the encryption used valid.
  • Time and state - Are race conditions introduced a components seek to share state.
  • Errors - Are there holes left in the code base that can be exploited.
  • Code Quality - Poor code quality introduces high risk situations and unpredictable behavior. The system may be stressed in unexpected ways.
  • Encapsulation - Are the boundaries between encapsulated code structures sound.
  • Environment - Anything outside the code base that might still be a security risk.

How do Static Code Analysis Tools Identify Problems Quickly?

First and foremost static analysis tools are efficient to use because they don't actually execute the code. These tools actually use what are known as static checkers which construct an abstract model of the code base and then travel through the program looking for patterns and common traps developers typically perform. Some of the most common and most useful criteria these static checkers use on this abstract model of the code base are:
  • Null Returns - Check to see if functions can return unexpected NULLs and create a segmentation fault
  • Forward Null - Check to see what paths generate a NULL pointer de-reference and create denial of service risks
  • Reverse Null - Check to see if pointers are checked against NULL before being de-referenced
  • Reverse Negative - Check to see if negative values are used in inappropriate places that open the program to security risk
  • Sizecheck - Check to see if correct memory allocation is used to prevent memory out of bounds errors
  • Resource Leak - Check to see if memory leaks exist that can introduce performance and crash problems
  • Use After Free - Check to see if once resources have been de-allocated from a heap, that these are not used again as they may cause nondeterministic results
  • Uninit Check to see if variables are initialized before use
  • Overrun Static - Check to see if there are invalid accesses to a static array which may lead to buffer overrun security risks
  • Overrun Dynamic - Check to see if there are invalid accesses to a dynamic array which may lead to buffer overrun security risks
  • Negative Returns - Check to see if a function returns a negative value that is returned inappropriately which may lead to memory corruption, crashes, infinite loops, etc.

Is Static Code Analysis Important?

Are There Drawbacks to Using Static Code Analysis?

Static Code Analysis in Dynamically Typed Languages

Static Code Analysis in Ruby

Conclusions

References