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

Compare with Current View Page History

« Previous Version 9 Next »

Formatting in Java is stricter as compared to traditional languages such as C. Exceptions are thrown if any conversion argument mismatches with the corresponding flag. Although not easily exploitable, it is possible for user input to taint the format string and cause information leakage or denial of service in some cases.

Noncompliant Code Example

This noncompliant example demonstrates a careless information leak. The code accepts the credit card expiration date as an input argument and uses it within the format string. In the absence of proper input validation, an artful attacker can observe the very date that has been asked to be inputted. Any of the arguments %1$tm, %1$te or %1$tY can further such an attempt.

import java.util.Calendar;
import java.util.GregorianCalendar;
import static java.util.Calendar.*;

class Format {
  static Calendar c = new GregorianCalendar(1995, 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
    //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);
  }
}

Compliant Solution

The perfect remedy to format string problems is to ensure that user generated input never shows up in format strings. This will safeguard the code from unforeseen exploitation.

import java.util.Calendar;
import java.util.GregorianCalendar;
import static java.util.Calendar.*;

class Format {
  static Calendar c = new GregorianCalendar(1995, 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", c);
  }
}

Risk Assessment

Allowing user input to taint the format string may cause information leakage or denial of service.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

FIO35-J

medium

probable

high

P4

L3

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

This rule appears in the C Secure Coding Standard as FIO30-C. Exclude user input from format strings.

This rule appears in the C++ Secure Coding Standard as FIO30-CPP. Exclude user input from format strings.

References

[[API 06]] Class Formatter
[[Seacord 05]] Chapter 6, Formatted Output


FIO34-J. Ensure all resources are properly closed when they are no longer needed      07. Input Output (FIO)      08. Concurrency (CON)

  • No labels