Do not operate on unvalidated or untrusted data (also known as tainted data) in a doPrivileged()
block. An attacker can supply malicious input that could result in privilege escalation attacks. Appropriate mitigations include hardcoding values rather than accepting arguments (when appropriate), or validating (a.k.a. sanitizing) date before the privileged operations.
Noncompliant Code Example
...
Code Block | ||
---|---|---|
| ||
static final String FILEPATH = "/path/to/protected/file/fn.ext"; private void privilegedMethod() throws FileNotFoundException { try { FileInputStream fis = (FileInputStream) AccessController.doPrivileged( new PrivilegedExceptionAction() { public FileInputStream run() throws FileNotFoundException { return new FileInputStream(FILEPATH); } } ); // do something with the file and then close it } catch (PrivilegedActionException e) { // forward to handler and log } } |
Risk Assessment
Allowing tainted inputs in privileged operations can lead to privilege escalation attacks.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SEC03-J | high | likely | low | P27 | L1 |
Automated Detection
Tools that support Taint Analysis enable code usage that is substantially similar to the Noncompliant Code Example. Typical taint analysis assumes that a method or methods exist(s) that can "clean" potentially tainted inputs, providing untainted outputs (or appropriate errors). The taint analysis then ensures that only untainted data is used inside the doPrivileged
block. Note that the static analysis necessarily assume that the cleaning methods are always successful; in reality this may not be the case.
Because the annotations used by the analysis tools vary, we present a notional example here.
Compliant Solution (Input Validation)
This compliant solution invokes a sanitization method (cleanAFilenameAndPath
) that can distinguish acceptable inputs from malicious inputs. Successful operation of the sanitization method indicates that the input is acceptable, and the doPrivileged
block can be executed.
Code Block | ||
---|---|---|
| ||
private void privilegedMethod(final String filename) throws FileNotFoundException { final String cleanFilename; try { cleanFilename = cleanAFilenameAndPath(filename); } catch (/* exception as per spec of cleanAFileNameAndPath */) { // log or forward to handler as appropriate based on specification // of cleanAFilenameAndPath } try { FileInputStream fis = (FileInputStream) AccessController.doPrivileged( new PrivilegedExceptionAction() { public FileInputStream run() throws FileNotFoundException { return new FileInputStream(cleanFilename); } } ); // do something with the file and then close it } catch (PrivilegedActionException e) { // forward to handler and log } } |
One potential drawback of this approach is that effective sanitization methods can be difficult to write. A benefit of this approach is that it works well in combination with taint analysis (see below).
Risk Assessment
Allowing tainted inputs in privileged operations can lead to privilege escalation attacks.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SEC03-J | high | likely | low | P27 | L1 |
Automated Detection
Tools that support taint analysis enable assurance of code usage that is substantially similar to the second compliant solution. Typical taint analysis assumes that a method or methods exist(s) that can "clean" potentially tainted inputs, providing untainted outputs (or appropriate errors). The taint analysis then ensures that only untainted data is used inside the doPrivileged
block. Note that the static analysis must necessarily assume that the cleaning methods are always successful; in reality this may not be the case.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
...