By Will Dormann
The Heartbleed bug, a serious vulnerability in the Open SSL crytographic software library, enables attackers to steal information that, under normal conditions, is protected by the Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption used to secure the internet. Heartbleed and its aftermath left many questions in its wake:
- Would the vulnerability have been detected by static analysis tools?
- If the vulnerability has been in the wild for two years, why did it take so long to bring this to public knowledge now?
- Who is ultimately responsible for open-source code reviews and testing?
- Is there anything we can do to work around Heartbleed to provide security for banking and email web browser applications?
In late April 2014, researchers from the Carnegie Mellon University Software Engineering Institute and Codenomicon, one of the cybersecurity organizations that discovered the Heartbleed vulnerability, participated in a panel to discuss Heartbleed and strategies for preventing future vulnerabilities. During the panel discussion, we did not have enough time to address all of the questions from our audience, so we transcribed the questions and panel members wrote responses. This blog posting presents questions asked by audience members during the Heartbleed webinar and the answers developed by our researchers. (If you would like to view the entire webinar, click here.)
By Robert C. Seacord
Secure Coding Technical Manager
Software developers produce more than 100 billion lines of code for commercial systems each year. Even with automated testing tools, errors still occur at a rate of one error for every 10,000 lines of code. While many coding standards address code style issues (i.e., style guides), CERT secure coding standards focus on identifying unsafe, unreliable, and insecure coding practices, such as those that resulted in the Heartbleed vulnerability. For more than 10 years, the CERT Secure Coding Initiative at the Carnegie Mellon University Software Engineering Institutehas been working to develop guidance—most recently, The CERT C Secure Coding Standard: Second Edition—for developers and programmers through the development of coding standards by security researchers, language experts, and software developers using a wiki-based community process. This blog post explores the importance of a well-documented and enforceable coding standard in helping programmers circumvent pitfalls and avoid vulnerabilities.
By Will Klieber
Member of the Technical Staff
This blog post was co-authored by Lori Flynn.
Although the Android Operating System continues to dominate the mobile device market (82 percent of worldwide market share in the third quarter of 2013), applications developed for Android have faced some challenging security issues. For example, applications developed for the Android platform continue to struggle with vulnerabilities, such as activity hijacking, which occurs when a malicious app receives a message (in particular, an intent) that was intended for another app but not explicitly designated for it. The attack can result in leakage of sensitive data or loss of secure control of the affected apps. Another vulnerability is exploited when sensitive information is leaked from a sensitive source to a restricted sink. This blog post is the second in a series that details our work to develop techniques and tools for analyzing code for mobile computing platforms. (A previous blog post, Secure Coding for the Android Platform, describes our team’s development of Android rules and guidelines.)
By Lori Flynn
Member of the Technical Staff
CERT Secure Coding team
Although the CERT Secure Coding team has developed secure coding rules and guidelines for Java, prior to 2013 we had not developed a set of secure coding rules that were specific to Java’s application in the Android platform. Android is an important area to focus on, given its mobile device market dominance (82 percent of worldwide market share in the third quarter of 2013) as well as the adoption of Android by the Department of Defense.
This blog post, the first in a series, discusses the initial
development of our Android rules and guidelines. This initial
development included mapping our existing Java secure coding rules and
guidelines to Android applicability and also the creation of new
Android- only rules for Java secure coding.
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.