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:

• The Army Mobile Handheld Computing Environment is an effort to devise an Android-based smartphone framework and suite of applications for tactical operations.
• The Defense Advanced Research Projects Agency (DARPA) also selected the Android platform for its transformative apps program, which aims to develop a diverse array of militarily-relevant software applications (apps) using a new development and acquisition process.

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:

• mapping our existing trove of Java secure coding rules, analyzing their applicability to the Android environment
• mapping our (at the time) in-development trove of Java secure coding guidelines, analyzing their applicability to the Android environment in time for that analysis to be included as an appendix in the published hardcopy book printed in 2013
• developing new Android-only rules and guidelines for Java development

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:

• Analysis for Android applicability of CERT Oracle secure coding rules and addition of Android-specific implementation advice to many of those rules on our wiki
  
  Our rules for Java are published in the book The CERT Oracle Secure Coding Standard for Java. The book was published in hard copy in September of 2011. Development of the standard continues on a wiki accessible and contributed to by the public but maintained by the CERT Secure Coding team. A summary of the analysis status at the end of 2013 is in Table 1 below.
  
  For Java rules found to require Android-specific implementation advice, a new section, Android Implementation Details, was added to that rule's wiki page just above the bibliography section.
• Analysis for Android applicability of CERT secure coding guidelines
  
  A team of researchers developed guidelines for secure coding in Java, which were initially published on the wiki site maintained by the CERT Secure Coding team. Those guidelines were published in the book Java Coding Guidelines, which was published in September.
  
  Not all of the Java guidelines that the CERT Secure Coding team had developed and published, however, could be applied to the Android OS. A summary of the analysis status at the end of 2013 is in Table 1 below. The full table with the current applicability analysis, with analysis details for each guideline, is here: Analysis of Applicability of CERT Java Secure Coding GUIDELINES to Android.

• DRD-labeled Android secure coding rules and guidelines
  
  We also created new rules and guidelines for Android secure coding. As we state on the wiki, the new rules and guidelines labeled "DRD" are applicable only to the Android platform. They do not apply to the development of Java programs for other platforms. The list of DRD rules below is current as of February 17, 2014, and can be found on our wiki:
  
  - Do not store sensitive information on external storage (SD card)
  - Limit the accessibility to your sensitive content provider
  - Do not allow WebView to access sensitive local resource through file scheme
  - Do not broadcast sensitive information using an implicit intent
  - Do not log sensitive information
  - Always canonicalize a URL received by a content provider
  - Restrict access to sensitive activities
  - Do not release apps that are debuggable

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.

Looking Ahead

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.

Additional Resources

To view the Android wiki on the CERT Secure Coding site, please visit
https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87150614

To read the SEI technical report, Mobile SCALe: Rules and Analysis for Secure Java and Android Coding, please visit
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=69225