Verification Validation of Open Source v2flightsoftware.jhuapl.edu/files/2011/FSW11_Uchenick.pdf · • Format string with untrusted source Performance inefficiencies • Big parameter

Verification & Validation of Open Source2011 WORKSHOP ON SPACECRAFT FLIGHT SOFTWARE

Gordon Uchenick

Coverity, Inc

Open Source is Ubiquitous

Confidential: For Coverity and Partner use only. Copyright Coverity, Inc., 20112

• Most commercial and proprietary software systems have some open source component

Open Source in Embedded Software

• According to Gartner, by 2012, 80% of commercial software development projects will include open-source components

• Popularity of Linux kernel

• Even proprietary operating systems have absorbed some open source components


The Challenges When Using Open Source

Incorporating open-source isn’t free or effortless:

1. Quality Risk – each developer tests according to his own requirements, probably limiting scope

2. Unit testing and integration testing have unknown rigor and coverage

3. Two ways of getting issues resolved:1. Report issues upstream and wait for patches

2. Dedicate internal resources to maintain open source and then feed fixes back into the community


How Static Analysis Can Help

Fewer defects escape dev

Design DevelopmentQuality

AssuranceProduct Release

Reduced Risk wrt Quality, Budget, & Schedule

Automated, Scalable, FastFinds and reports defects in all parts of the code as well as defects

due to integration

How Static Analysis Works

Explains the location and root cause of defects

Manage and share triage of defects across teams

Mimicks the behavior of dozens of compilers

Integrates with existing build systems

Statically tests all execution paths

Finds defects and inconsistent coding patterns

AnalyzeBuildPresent & Manage

Static Analysis for Managing Risk from Open Source

1. Use static analysis to automate defect detection across the entire code base, including open source components

1. Having all source code instead of just API contracts enables a more complete analysis

2. Fixes can be verified1. Did I fix the problem?

2. Did I break anything else?


Most Commonly Found Defects In Open Source


Frequency in SCAN projects Risk

NULL Pointer Dereference 27.60% Medium

Resource Leak 23.19% High

Unintentional Expressions 9.76% Medium

Uninitialized Values Read 8.41% High

Use After Free 5.91% High

Buffer Overflow 5.52% High

Coverity SCAN: Accelerating Open Source Software Integrity• Established in 2006 in collaboration with US Department of Homeland Security

• http://scan.coverity.com


2009 2010

Total LOC scanned 11.5 billion 14.5 billion

Total Open Source Projects analyzed

280 291

Total Defects Found 38,453 49,654

Total Defects Fixed 11,246 15,278

Resources

• Coverity SCAN project: http://scan.coverity.com

• Software Integrity Risk Report: http://www.coverity.com/Forrester-Software-Integrity-Risk/

• 2010 SCAN Report: http://softwareintegrity.coverity.com/2011ScanAndroidReg.html


Thank You

Appendix

A few Static Analysis examples

Resource Leaks • Memory leaks• Resource leak in object• Incomplete delete• Microsoft COM BSTR memory leak

Uninitialized variables• Missing return statement• Uninitialized pointer/scalar/array read/write• Uninitialized data member in class or

structureConcurrency Issues

• Deadlocks• Race conditions• Blocking call misuse

Integer handling issues• Improper use of negative value• Unintended sign extension

Improper Use of APIs• Insecure chroot• Using invalid iterator• printf() argument mismatch

Memory-corruptions

• Out-of-bounds access

• String length miscalculations

• Copying to destination buffers too small

• Overflowed pointer write

• Negative array index write

• Allocation size error

Memory-illegal access

• Incorrect delete operator

• Overflowed pointer read

• Out-of-bounds read

• Returning pointer to local variable

• Negative array index read

• Use/read pointer after free

Control flow issues

• Logically dead code

• Missing break in switch

• Structurally dead code

Error handling issues

• Unchecked return value

• Uncaught exception

• Invalid use of negative variables

C/C++ Defects That Coverity Can FindPart 1

Program hangs

• Infinite loop

• Double lock or missing unlock

• Negative loop bound

• Thread deadlock

• sleep() while holding a lock

Null pointer differences

• Dereference after a null check

• Dereference a null return value

• Dereference before a null check

Code maintainability issues

• Multiple return statements

• Unused pointer value

Insecure data handling

• Integer overflow

• Loop bound by untrusted source

• Write/read array/pointer with untrusted value

• Format string with untrusted source

Performance inefficiencies

• Big parameter passed by value

• Large stack use

Security best practices violations

• Possible buffer overflow

• Copy into a fixed size buffer

• Calling risky function

• Use of insecure temporary file

• Time of check different than time of use

• User pointer dereference

C/C++ Defects That Coverity Can FindPart 2

C/C++ Resource Leaks

• Resource leaks occur when variables go out of scope while “owning” a resource

• Memory leaks are one of the most common kinds of resource leaks

15

Technical ImpactCrashes, inability to allocate more resources,Vulnerability to denial of service attacks


Example C++ Memory Leak

16

Allocating memoryinto member field

Destructor does not freemember field


Example Memory Leak

17

Allocated “names”

Allocated other variables

Checking for allocationfailures for all variables

Freeing the wrongvariable in cleanup code.Cut and paste error?

“names” leaked

Bonus: potential double free


C++ Memory Leak with Incorrect Delete

18

Allocating array ofobjects

Using delete instead ofdelete[] means destructoris not called, leaking thememory in the fields.

Constructor for eachobject allocates field


Other C/C++ Resource Leaks

• Coverity also detects incorrect delete patterns such as:

delete a, b; // comma operator means only “a” is deleted

• Resource leaks on handles that refer to files, sockets, and other system resources


C/C++ Memory Corruption

• Memory corruption occurs when programs write to memory outside of the bounds of memory buffers

• Buffer overflow is another common name for memory corruption

20

Technical ImpactCrashes, unexpected behavior, security vulnerabilities


Example Memory Corruption

21

Table has 6 ints,valid indices are 0..5

Loop from 0 tosizeof(table)

Table indexed pastthe end of thearray becausesizeof(table) ismeasured in bytes


Example Memory Corruption

22

Assigning identto a constant string

Freeing constantstring causes memorycorruption


Example Double Free

23

Freeing “buf1”

Freeing “buf1” again,copy and paste error

Bonus: memory leakon “buf3”


Example Buffer Overflow

24

Possible securityvulnerabilitythrough stackbuffer overflow


Example String Buffer Escape

25

C++ string “s”is destroyed whenfunction returns,making the pointerreturned from c_str()invalid. The caller ofthis function will findstack garbage there,caused unexpectedbehavior and possiblya crash.


Other Memory Corruption Defects Coverity Can Detect

• Coverity looks for over a dozen different patterns of memory corruption including:

• String length miscalculations

• Copying to too small destination buffers

• Negative array index write

• Allocation size error

• Integer overflow

26 Confidential: For Coverity and Partner use only. Copyright Coverity, Inc., 2011

Documents

Verification Validation of Open Source v2flightsoftware.jhuapl.edu/files/2011/FSW11_Uchenick.pdf · • Format string with untrusted source Performance inefficiencies • Big parameter