Software is ubiquitous, affecting all aspects of our personal and professional lives. Software vulnerabilities are equally ubiquitous. Poor software development quality is a top threat in the next 12 months.
Software is ubiquitous, affecting all aspects of our personal and professional lives. Software vulnerabilities are equally ubiquitous. Poor software development quality is a top threat in the next 12 months.
Software is ubiquitous, affecting all aspects of our personal and professional lives. Software vulnerabilities are equally ubiquitous. Poor software development quality is a top threat in the next 12 months.
Software is ubiquitous, affecting all aspects of our personal and professional lives. Software vulnerabilities are equally ubiquitous. Poor software development quality is a top threat in the next 12 months.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
You are on page 1/ 59
Secure Coding
2008 Census Bureau Software Process Improvement Conference
Developed nations economies and defense depend, in large part, on the reliable execution of software Software is ubiquitous, affecting all aspects of our personal and professional lives. Software vulnerabilities are equally ubiquitous, jeopardizing: Personal identities Intellectual property Consumer trust Business services, operations,
& continuity Critical infrastructures & government
Increasing Vulnerabilities Reacting to vulnerabilities in existing systems is not working
Deloitte 2007 Global Security Survey
Finding #3: Application security:
generic countermeasures are no longer adequate Applications are the primary gateway to sensitive data 87% of respondents: poor
software development quality is a top threat in the next 12 months
Application security is the #1
issue for CIOs (Gartner)
Deloitte 2007 Global Security Survey: The Shifting Security Paradigm. Deloitte, September 2007. http://www.deloitte.com/dtt/cda/doc/content/dtt_gfsi_GlobalSecuritySurvey_20070901(1).pdf 5
Vulnerabilities Cost Vendors
A study based on real vulnerability announcements in 19992004 revealed: an average drop of the concerned vendor's stock price of 0.6% after each vulnerability announcement
Tehang / Wattal, Carnegie Mellon Univerisity, 2004 "Impact of Software Vulnerability Announcements on the Market Value of Software Vendors an Empirical Investigation"
... not to mention the damage to the vendor's reputation
So What Is Software Security?
Not the same as security software Firewalls, intrusion detection, encryption Protecting the environment within which the software
operates
Engineering software so that it continues to function under attack The ability of software to recognize, resist, tolerate, and recover from events that threaten it Goal: Better, defect-free software that can function more robustly in its operational production environment 7
Application Security
Sources of Software Insecurity 1
Complexity, inadequacy, and change Incorrect or changing assumptions (capabilities, inputs, outputs) Flawed specifications & designs Poor implementation of software interfaces (input validation, error & exception handling) Inadequate knowledge of secure coding practices
Sources of Software Insecurity 2
Unintended, unexpected interactions with other components with the softwares execution environment
Absent or minimal consideration of security during all life cycle phases Not thinking like an attacker
10
Most Vulnerabilities caused by Programming Errors
64% of the vulnerabilities in NVD in 2004 are due to programming errors 51% of those due to classic errors like buffer overflows,
cross-site-scripting, injection flaws Heffley/Meunier (2004): Can Source Code Auditing Software Identify Common Vulnerabilities and Be Used to Evaluate Software Security?
Cross-site scripting, SQL injection at top of the statistics (CVE, Bugtraq) in 2006 We wouldn't need so much network security if we didn't have such bad software security --Bruce Schneier 11
Coding Securely May Be Harder Than You Think! char x, y; x = -128; y = -x; if if if if if (x == y) puts("1"); ((x - y) == 0) puts("2"); ((x + y) == 2 * x) puts("3"); (((char)(-x) + x) != 0) puts("4"); (x != -y) puts("5");
12
W32.Blaster.Worm Infected unpatched system connected to the Internet without user involvement. At least eight million Windows systems have been infected by this worm [Lemos 04]. Exploits a vulnerability in the DCOM RPC interface of Windows. Propagates via TCP/IP. Economic damage estimated to be at least $525 million.
13
Blaster Timeline (2003)
RPC Vulnerability discovered by Last Stage of Delirium (LSD) July 25: Xfocus releases exploit August 2-3: Defcon hacker convention August 12: 336,000 computers infected
July 16: Microsoft releases security bulletin
August 2: Indications of attacks sent through Internet Relay Chat (IRC) networks discovered
August 11: Blaster discovered spreading through the Internet August 14: Over 1 million computers infected
July 17: CERT issues advisory
14
How Blaster Works
Checks to see if the computer is already infected. Runs when Windows starts. Generates a random IP address. Attempts to infect the computer with that address. Sends data on TCP port 135 to exploit the DCOM RPC vulnerability on either Windows XP or Windows 2000.
An unexpected value is not one you would expect to get using a pencil and paper Unexpected values are a common source of software vulnerabilities (even when this behavior is correct).
17
Bourne Again Shell 1
GNUs Bourne Again Shell (bash) is a drop-in replacement for the Bourne shell (/bin/sh). same syntax as the standard shell but provides
additional functionality such as job control, command-line editing, and history.
most prevalent use is on Linux.
A vulnerability exists in bash versions 1.14.6 and earlier where bash can be tricked into executing arbitrary commands.
18
Bourne Again Shell 2
Bash contains an incorrectly declared variable in the yy_string_get() function responsible for parsing the user-provided command line into separate tokens. The error involves the variable string, which has been declared to be of type char *. The string variable is used to traverse the character string containing the command line to be parsed.
19
Bourne Again Shell 3
As characters are retrieved from this pointer, they are stored in a variable of type int. For compilers in which the char type defaults to signed char, this value is sign-extended when assigned to the int variable. For character code 255 decimal (-1 in twos complement form), this sign extension results in the value -1 being assigned to the integer. -1 is used in other parts of the parser to indicate the end of a command.
20
Bourne Again Shell 4
The character code 255 decimal (377 octal) serves as an unintended command separator for commands given to bash via the -c option. Example: bash -c 'ls\377who'
(where \377 represents the single character with value 255 decimal) executes two commands, ls and who.
21
Integer Security Integers represent a growing and underestimated source of vulnerabilities in programs. Integer range checking has not been systematically applied in the development of most software. security flaws involving integers exist a portion of these are likely to be vulnerabilities
Work with software developers and software development organizations to eliminate vulnerabilities resulting from coding errors before they are deployed. Reduce the number of vulnerabilities to a level where
they can be handled by computer security incident response teams (CSIRTs)
Decrease remediation costs by eliminating vulnerabilities
before software is deployed
We dont make the software you use, we make the software you use run slower. 25
Overall Thrusts Advance the state of the practice in secure coding Identify common programming errors that lead to software vulnerabilities Establish standard secure coding practices Educate software developers
26
Current Capabilities Secure Coding in C and C++ Addison-Wesley book Training
Secure coding web pages www.cert.org/secure-coding/ Secure string and integer library development Involvement in international standards activities: ISO/IEC JTC1/SC22/WG14 C programming language
international standardization working group
ISO/IEC JTC1/SC22 OWG Vulnerabilities
27
Current and Planned Efforts
CERT Secure Coding Standards C and C++ Programming Language Community development process
Training courses Direct offerings Partnered with industry
Software Validation and Verification
Partner with software tool vendors to validate
conformance to secure coding standards
Partner with software development organizations to
evaluate the application of secure coding standards
28
CMU CS 15392 Secure Programming
Offered as an undergraduate elective in the School of Computer Science in S07 and S08 More of a vocational course than an enduring
knowledge course. Students are interested in taking a class that goes
beyond policy
Course page including lecture slides (PDF):
www.securecoding.cert.org/confluence/display/sci/15392+Secure+Program ming
29
Secure Coding in C/C++ Training
Secure Coding in C and C++ provides practical guidance on secure programming provides a detailed explanation of common programming
errors describes how errors can lead to vulnerable code evaluates available mitigation strategies
Useful to anyone involved in developing secure C and C++ programs regardless of the application
Identify coding practices that can be used to improve the security of software systems under development Coding practices are classified as either rules or recommendations Rules need to be followed to claim compliance. Recommendations are guidelines or suggestions.
Development of Secure Coding Standards is a community effort
32
Scope The secure coding standards proposed by CERT are based on documented standard language versions as defined by official or de facto standards organizations. Secure coding standards are under development for: C programming language (ISO/IEC 9899:1999) C++ programming language (ISO/IEC 14882-2003 )
Applicable technical corrigenda and documented language extensions such as the ISO/IEC TR 24731 extensions to the C library are also included.
33
Secure Coding Web Site (Wiki)
34
Rules Coding practices are defined as rules when Violation of the coding practice will result in a security
flaw that may result in an exploitable vulnerability.
There is an enumerable set of exceptional conditions (or
no such conditions) where violating the coding practice is necessary to ensure the correct behavior for the program. Conformance to the coding practice can be verified.
35
36
MEM31-C. Compliant Solution
37
Recommendations Coding practices are defined as recommendations when Application of the coding practice is likely to improve
system security. One or more of the requirements necessary for a coding
practice to be considered as a rule cannot be met.
38
MEM00-A. Allocate and free memory in the same module, at the same level of abstraction Allocating and freeing memory in different modules and levels of abstraction burdens the programmer with tracking the lifetime of that block of memory. This may cause confusion regarding when and if a block of memory has been allocated or freed, leading to programming defects such as double-free vulnerabilities, accessing freed memory, or writing to unallocated memory. To avoid these situations, it is recommended that memory be allocated and freed at the same level of abstraction, and ideally in the same code module. Freeing memory in different modules resulted in a vulnerability in MIT Kerberos 5 MITKRB5-SA-2004-002 .
39
Non-Compliant Coding Example
void func2(int *list, size_t list_size) { if (size < MIN_SIZE) { If unable to process, list is freed, and free(list); the function returns. return; } If the number of elements in the array is greater /* Process list */ than MIN_SIZE, the array is processed. } void func1 (size_t number) { Array of integers is int *list = malloc(number * sizeof(int)); allocated. if (list == NULL) { /* Handle Allocation Error */ The array and its } size are passed to func2(list, number); func2(). /* Continue Processing list */ free(list); } If the error occurs in func2(), memory referred to by list is freed twice: once in func2() and again in func1() 40
Compliant Solution void func2(int *list, size_t list_size) { if (size < MIN_SIZE_ALLOWED) { /* Handle Error Condition */ return; } Eliminated free() /* Process list */ in support function. } void func1 (size_t number) { int *list = malloc (number * sizeof(int)); if (list == NULL) { /* Handle Allocation Error */ } func2(list,number); /* Continue Processing list */ free(list); }
Rules are solicited from the community Published as candidate rules and recommendations on the CERT Wiki at: www.securecoding.cert.org
Threaded discussions used for public vetting Candidate coding practices are moved into a secure coding standard when consensus is reached
43
Priorities and Levels
High severity, likely, inexpensive to repair flaws L1 P12-P27
L2 P6-P9
L3 P1-P4
Med severity, probable, med cost to repair flaws
Low severity, unlikely, expensive to repair flaws
44
FIO30-C. Exclude user input from format strings
45
CERT Mitigation Information
Vulnerability Note VU#649732 This vulnerability occurred as a result of failing to comply with rule FIO30-C of the CERT C Programming Language Secure Coding Standard.
US CERT Technical Alerts
CERT Secure Coding Standard
Examples of vulnerabilities resulting from the violation of this recommendation can be found on the CERT website . 46
Secure Coding Standard Applications
Establish secure coding practices within an organization may be extended with organization-specific rules cannot replace or remove existing rules
Train software professionals Certify programmers in secure coding Establish requirements for software analysis tools Certify software systems 47
Software Validation & Verification
Implementing checkers for various software analysis tools to verify compliance with CERT secure coding standards Fortify SCA Lawrence Livermore National Laboratory (LLNL)
Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05]. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code. Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set. 50
Top 10 Secure Coding Practices
4.
5.
Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex. Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75]. 51
Top 10 Secure Coding Practices
6.
7.
Adhere to the principle of least privilege. Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75]. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem. 52
Top 10 Secure Coding Practices
8.
9.
10.
Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05]. Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Penetration testing, fuzz testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05]. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.
53
Bonus Secure Coding Practices
1.
2.
Define security requirements. Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated. Model threats. Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases [Swiderski 04].
54
Future Directions Continue to develop and enhance existing secure coding standards and associated checkers Develop secure coding standards for other languages and programming environments Java Web Development Language independent Ada, SPARK
Develop secure coding design patterns
55
Key Points Everyday software defects cause the majority of software vulnerabilities. Software developers are not always properly trained and equipped to program securely. The result is numerous delivered defects, some of which can lead to vulnerabilities. Understanding the sources of vulnerabilities and learning to program securely is imperative to protecting the Internet and ourselves from attack.
56
References [Saltzer 74] Saltzer, J. H. "Protection and the Control of Information Sharing in Multics." Communications of the ACM 17, 7 (July 1974): 388-402. [Saltzer 75] Saltzer, J. H. & Schroeder, M. D. "The Protection of Information in Computer Systems." Proceedings of the IEEE 63, 9 (September 1975), 1278-1308. [Seacord 05] Seacord, R. Secure Coding in C and C++. Upper Saddle River, NJ: Addison-Wesley, 2006 (ISBN 0321335724). [Swiderski 04] Swiderski, F. & Snyder, W. Threat Modeling. Redmond, WA: Microsoft Press, 2004. 57
Questions 58
For More Information
Visit CERT web sites: http://www.cert.org/secure-coding/ https://www.securecoding.cert.org/
