Posted on by
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.
Motivation for Our Work
Software programmers produce more than 100 billion new lines of code for commercially available software put into operation each year, according to a recent article published in Defense Systems. Meanwhile, programming errors happen at an estimated rate of 15 to 50 errors per 1,000 lines of code. Even with the advent of automated testing tools, the article states that "numerous studies and a substantial amount of research suggest that approximately one error per every 10,000 lines of production code still exists after testing. That would equate to 10,000,000 errors in the code produced each year."
To help cope with this enormous problem, the CERT Secure Coding team has developed a set of secure coding standards providing rules and guidelines that programmers and analysis tools can use to evaluate source code for compliance to the standards, which can help developers avoid or discover errors that make code insecure. A rule is advice for secure coding which is normative: a violation of the secure coding advice always must constitute a defect in the code. If the recommendation depends on programmer intention, then it might not be possible to automatically enforce the recommendation, and it is not considered normative.) A guideline is a secure coding recommendation that is excluded from being defined as a rule because it is not possible to form a normative requirement around it.
For example, if a recommendation depends on programmer intention, then it might not be possible to automatically enforce the recommendation. Even if the recommendation is always a good idea, if violation of the recommendation does not always constitute a defect in the code, the recommendation is a guideline, not a rule.
There have been several recent initiatives by the DoD to incorporate the Android OS into its mobile computing strategy:
Foundations of Our Work
Our project aims to create rules that can be verified and enforced, as well as to develop a means for checking code for violations of these rules. This research was part of the Source Code Analysis Laboratory (SCALe). The Mobile SCALe project is extending this existing CERT concept to create a source code analysis laboratory environment for the analysis of code for mobile computing platforms. The first platform that Mobile SCALe has focused on is Android.
Our work was led by a team of researchers who, in addition to myself, included William Klieber, Dr. Dean Sutherland, and David Svoboda of the CERT Secure Coding team; Dr. Lujo Bauer and Dr. Limin Jia of Carnegie Mellon University's Department of Electrical and Computer Engineering; and Dr. Fred Long of Aberystwyth University. The Japan Computer Emergency Response Team Coordination Center (JPCERT), including Masaki Kubo, Hiroshi Kumagai, and Yozo Toda, assisted in the development of the Android secure coding rules and guidelines.
Our Mobile SCALe work can be separated into coding rules and guidelines development and static analysis development phases, which will guide the development of blog posts in this series.
Our work in 2013 to develop Android secure coding rules and guidelines involved three main tasks:
Rules and Guidelines for Java Secure Coding for Android
As we outlined in our recently published technical report, Mobile SCALe: Rules and Analysis for Secure Java and Android Coding, we started developing secure coding rules and guidelines for Android by focusing on a specific language, Java, and adding an Android section to the CERT Oracle Secure Coding Standard for Java wiki. Although Android apps can be written in native code, such as C or C++, our 2013 work focused only on the Java language.
Hosting secure coding rules and guidelines on our secure coding wiki allows us to collaboratively create these coding standards with assistance from the development and security communities, vet it with expert opinion, and receive feedback. Android secure coding advice also exists elsewhere, but we found it in incomplete sets and in disparate locations across the web. One technique we use to develop new coding standards is to mine our other CERT secure coding standards. Many of our rules from C/C++/Java apply to C#. A second technique we use is to mine vulnerability databases, using public databases such as the Department of Homeland Security's National Vulnerability Database, and sometimes CERT also is provided or develops privately held information about vulnerabilities. A third standard technique we use is to mine current literature. We found useful advice for secure Java coding for Android in separate locations, such as the Android developer website, Google, and security researcher websites, as well as research papers, online articles, and security conference presentations.
We use a standardized format for all coding rules and guidelines (whether they are C, C++, Java, Perl, or Android-only) on our wiki. Each begins with a summary of the rule or guideline and an explanation of security issues it addresses. Then the wiki lists an example of non-conforming code and explains why it's a problem. The wiki also includes references where readers can go for more information. We also provide a score that encases the severity of any vulnerability and the likelihood that the vulnerability can be exploited as well as an analysis of the cost of remediation if a violation is found in the code.
Consider the following excerpts from our one of our guidelines applicable to secure development of Android apps:
DRD00-J. Do not store sensitive information on external storage (SD card)
Android provides several options to save persistent application data, one of which is External Storage, such as /sdcard or /mnt/sdcard.
Files saved to the external storage are world-readable. Consequently, they can be modified by other apps installed on the device or by the user (by enabling USB mass storage and manipulating files from a PC).
The Android API Guides [Android Guides 2013] Storage Options states:
Caution: External storage can become unavailable if the user mounts the external storage on a computer or removes the media, and there's no security enforced upon files you save to the external storage. All applications can read and write files placed on the external storage and the use can remove them.
[Guideline]. Developers should not store sensitive data to external storage devices because files stored externally have no guarantee of confidentiality integrity, and availability.
Noncompliant Code Example
The following code creates a file on the external storage and saves sensitive information to the file:
Compliant Solution (Save a File on Internal Storage)
The following code uses the openfileoutput () method to create "myfile" in an application data directory with permission set to MODE_PRIVATE so that other apps cannot access the file:
Likelihood/Severity. We make three numerical estimates, based on our understanding of the security issues addressed by the secure coding advice (the rule or guideline). Severity estimates the consequences if the advice is ignored. Likelihood estimates how likely it is that a flaw introduced by violating the rule or guideline could lead to an exploitable vulnerability. Remediation cost estimates how expensive it is to remediate existing code to comply with the advice. Our analysis found that the severity of a problem such as the one illustrated above would be high, and that the likelihood would be probable. The cost to remediate such a problem would be medium, since automatic detection with manual correction is possible if sensitive data sources are identified.
The above format can be found for each of the CERT secure coding rules and guidelines.
Three sections of the wiki were developed in 2013:
Two of the eight Android-only rules are actually Android-specific instances of more general Java rules: one concerning the logging of sensitive data and the other the canonicalization of file path names. Four of the remaining six rules focus on the handling of sensitive data by Android apps. In particular, these rules highlight aspects of Android programming that could lead unwary programmers to release sensitive data by misusing features of the Android architecture.
The next post in this series will focus on the development of two tools that analyze information flow within and between Android apps. One of these tools analyzes potential communication between apps by focusing specifically on the sending and receiving of intents, which are a core inter-app communication mechanism in Android. Tracing these intents can be challenging because there are typically multiple methods of entry into a program. The blog post will also discuss a new static analysis tool we are developing. Later this year, we will also post about our ongoing Android secure coding work: expanding the coding rules and guidelines beyond Java and further development of our newest static analysis tool.
To view the Android wiki on the CERT Secure Coding site, please visit
To read the SEI technical report, Mobile SCALe: Rules and Analysis for Secure Java and Android Coding, please visit