Mar 25
2013
By David Svoboda
CERT Secure Coding Team
This
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.
Read more...
Nov 26
2012
By Douglas C. Schmidt
Principal Researcher
As
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.
Read more...
Nov 5
2012
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.
Read more...
Jun 25
2012
David Svoboda
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.
Read more...
Jun 18
2012
By David Keaton,
Researcher
The CERT Secure Coding Program
Buffer overflows—an
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).
Read more...
Recent Comments