You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 73 Next »

Interpretation of Java format strings is stricter than in languages such as C [Seacord 2005]. The standard library implementations throw appropriate exceptions when any conversion argument fails to match the corresponding format specifier. This approach reduces opportunities for malicious exploits. Nevertheless, malicious user input can exploit format strings and can cause information leaks or denial of service. As a result, strings from an untrusted source should not be incorporated into format strings.

Noncompliant Code Example

This noncompliant code example demonstrates an information leak issue. It accepts a credit card expiration date as an input argument and uses it within the format string.

class Format {
  static Calendar c = 
   new GregorianCalendar(1995, GregorianCalendar.MAY, 23);
  public static void main(String[] args) {  
    // args[0] is the credit card expiration date
    // args[0] can contain either %1$tm, %1$te or %1$tY as malicious
    // arguments
    // First argument prints 05 (May), second prints 23 (day) 
    // and third prints 1995 (year)
    // Perform comparison with c, if it doesn't match print the 
    // following line
    System.out.printf(args[0] + 
    " did not match! HINT: It was issued on %1$terd of some month", c);
  }
}

In the absence of proper input validation, an attacker can determine the date against which the input is being verified by supplying an input that includes one of the format string arguments %1$tm, %1$te, or %1$tY.

Compliant Solution

This compliant solution ensures that user-generated input is excluded from format strings.

class Format {
  static Calendar c = 
    new GregorianCalendar(1995, GregorianCalendar.MAY, 23);
  public static void main(String[] args) {  
    // args[0] is the credit card expiration date
    // Perform comparison with c, 
    // if it doesn't match print the following line
    System.out.printf("The input did not match! "
        + " HINT: It was issued on %1$terd of some month", args[0],c);
  }
}

Risk Assessment

Allowing user input to taint a format string may cause information leaks or denial of service.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

IDS06-J

medium

unlikely

medium

P4

L3

Automated Detection

Static analysis tools that perform taint analysis can diagnose some violations of this rule.

Related Guidelines

CERT C Secure Coding Standard

FIO30-C. Exclude user input from format strings

CERT C++ Secure Coding Standard

FIO30-CPP. Exclude user input from format strings

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="47ddee95-02a7-406a-bad1-6704db34f1d6"><ac:plain-text-body><![CDATA[

[ISO/IEC TR 24772:2010

http://www.aitcnet.org/isai/]

Injection [RST]

]]></ac:plain-text-body></ac:structured-macro>

MITRE CWE

CWE-134. Uncontrolled format string

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d658e914-7398-40d9-abfc-3eaa728e164e"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

[Class Formatter

http://java.sun.com/javase/6/docs/api/java/util/Formatter.html]

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b93be4a6-a488-4b3e-b4f2-960ff767e361"><ac:plain-text-body><![CDATA[

[[Seacord 2005

AA. Bibliography#Seacord 05]]

Chapter 6, Formatted Output

]]></ac:plain-text-body></ac:structured-macro>


IDS05-J. Use a subset of ASCII for file and path names            IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method

  • No labels