By David Svoboda
CERT Secure Coding Team
blog post describes a research initiative aimed at eliminating
vulnerabilities resulting from memory management problems in C and C++.
Memory problems in C and C++ can lead to serious software
vulnerabilities including difficulty fixing bugs, performance
impediments, program crashes (including null pointer deference and out-of-memory errors), and remote code execution.
By Douglas C. Schmidt
part of an ongoing effort to keep you informed about our latest work,
I'd like to let you know about some recently published SEI technical
reports and notes. These reports highlight the latest work of SEI
technologists in information assurance and agile, the Team Software Process (TSP), CERT secure coding standards, resource allocation, fuzzing, cloud computing interoperability, and cloud computing at the tactical edge.
This post includes a listing of each report, author(s), and links where
the published reports can be accessed on the SEI website.
By David Keaton,
Senior Member of the Technical Staff
CERT Secure Coding Team
By analyzing vulnerability reports for the C, C++, Perl, and Java programming languages, the CERT Secure Coding Team
observed that a relatively small number of programming errors leads to
most vulnerabilities. Our research focuses on identifying insecure
coding practices and developing secure alternatives that software
programmers can use to reduce or eliminate vulnerabilities before
software is deployed. In a previous post, I described our work to identify vulnerabilities that informed the revision of the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standard for the C programming language. The CERT Secure Coding Team has also been working on the CERT C Secure Coding Standard,
which contains a set of rules and guidelines to help developers code
securely. This posting describes our latest set of rules and
recommendations, which aims to help developers avoid undefined and/or
unexpected behavior in deployed code.
Software Security Engineer
CERT Secure Coding Initiative
As security specialists, we are often asked to audit software and provide expertise on secure coding practices.
Our research and efforts have produced several coding standards
specifically dealing with security in popular programming languages,
such as C, Java, and C++. This posting describes our work on the CERT Perl Secure Coding Standard, which provides a core of well-documented and enforceable coding rules and recommendations for Perl, which is a popular scripting language.
By David Keaton,
The CERT Secure Coding Program
all too common problem that occurs when a program tries to store more
data in a buffer, or temporary storage area, than it was intended to
hold—can cause security vulnerabilities. In fact, buffer overflows led to the creation of the CERT program, starting with the infamous 1988 “Morris Worm” incident
in which a buffer overflow allowed a worm entry into a large number of
UNIX systems. For the past several years, the CERT Secure Coding team
has contributed to a major revision of the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standard for the C programming language.
Our efforts have focused on introducing much-needed enhancements to C
and its standard library to address security issues, such as buffer
overflows. These security enhancements include (conditional) support for
bounds-checking interfaces, (conditional) support for analyzability,
static assertions, “no-return” functions, support for opening files for
exclusive access, and the removal of the insecure gets() function. This
blog posting explores two of the changes—bounds-checking interfaces and
analyzability—from the December 2011 revision of the C programming
language standard, which is known informally as C11 (each revision of the standard cancels and replaces the previous one, so there is only one C standard at a time).