Programs must comply with the principle of least privilege not only by providing privileged blocks with the minimum permissions required for correct operation (see SEC50-JGJ. Avoid granting excess privileges) , but also by ensuring that privileged code contains only those operations that require the increased privileges. Superfluous code contained within a privileged block necessarily operates must operate with the privileges of that block; , increasing the attack surface.
Noncompliant Code Example
This noncompliant code example contains a changePassword()
method that attempts to open a password file within a doPrivileged
block and performs operations using that file. The doPrivileged
block also contains a superfluous System.loadLibrary()
call that loads the authentication library.
Code Block | ||
---|---|---|
| ||
public void changePassword(String currentPassword, String newPassword) { final FileInputStream f[] = { null }; AccessController.doPrivileged(new PrivilegedAction() { public Object run() { try { String passwordFile = System.getProperty("user.dir") + File.separator + "PasswordFileName"; f[0] = new FileInputStream(passwordFile); // Check whether oldPassword matches the one in the file // If not, throw an exception System.loadLibrary("authentication"); } catch (FileNotFoundException cnf) { // Forward to handler } return null; } }); // endEnd of doPrivileged() } |
This example violates the principle of least privilege because an unprivileged caller will could also cause the authentication library to be loaded. An unprivileged caller should not be allowed to invoke cannot invoke the System.loadLibrary()
method especially via the doPrivileged
mechanism because directly because this could expose native methods to the unprivileged code [SCG 2010]. Furthermore, the System.loadLibrary
uses ()
method checks only the immediate caller's class loader to find and load the library. Unprivileged code is seldom granted privileges to load libraries because doing so would expose native methods to the unprivileged code [SCG 2010] privileges of its immediate caller, so it should be used only with great care. For more information, see SEC52-J. Do not expose methods that use reduced-security checks to untrusted code.
Compliant Solution
This compliant solution moves the call to System.loadLibrary()
outside the doPrivileged()
block. That Doing so allows unprivileged code to perform preliminary password - reset checks using the file but prevents it from loading the authentication library.
Code Block | ||
---|---|---|
| ||
public void changePassword(String currentPassword, String newPassword) { final FileInputStream f[] = { null }; AccessController.doPrivileged(new PrivilegedAction() { public Object run() { try { String passwordFile = System.getProperty("user.dir") + File.separator + "PasswordFileName"; f[0] = new FileInputStream(passwordFile); // Check whether oldPassword matches the one in the file // If not, throw an exception } catch (FileNotFoundException cnf) { // Forward to handler } return null; } }); // endEnd of doPrivileged() System.loadLibrary("authentication"); } |
The loadLibrary()
invocation could also occur before performing preliminary password - reset checks are performed; in this case example, it is deferred for performance reasons.
Applicability
Minimizing privileged code reduces the attack surface of an application and simplifies the task of auditing privileged code.
Related Guidelines
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.SEC51.PCL | Limit the number of lines in "privileged" code blocks | ||||||
"Privilege Sandbox Issues [XYO]" | |||||||||
CWE ID 272, "Least Privilege Violation" | |||||||||
[SCG 2010] | Guideline 9-9: Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance |
Bibliography
...