Page History

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-J. Avoid granting excess privileges) but also by ensuring that privileged code contains only those operations that require increased privileges. Superfluous code contained within a privileged block must operate with the privileges of that block, increasing the attack surface.

Noncompliant Code Example

This noncompliant code example shows contains a changePassword() method that attempts to open a password file using within a doPrivileged block and performs operations using that file. The doPrivileged block also contains logic that operates on the file and a superfluous System.loadLibrary() call that loads the authentication library.

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);                                                     
        // Operations on Check whether oldPassword matches the one in the file ...
        // If not, throw an exception
        System.loadLibrary("LibNameauthentication");
      } catch (FileNotFoundException cnf) {
        // Forward to handler
      }
      return null;
    }
  }); // endEnd of doPrivileged()
}

This is a violation of example violates the principle of least privilege because a caller who does not have the required privileges can indirectly load the library provided the security policy allows doing so. This transfers the burden of ensuring security to the administrator who implements the security policy.

Compliant Solution

because an unprivileged caller could also cause the authentication library to be loaded. An unprivileged caller cannot invoke the System.loadLibrary() method directly because this could expose native methods to the unprivileged code [SCG 2010]. Furthermore, the System.loadLibrary() method checks only the 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. Doing so allows unprivileged code to perform preliminary password reset checks using the file but prevents it from loading the authentication library.  Wiki MarkupThis compliant solution removes the call to {{System.loadLibrary()}}. Any operations on the file descriptor {{f\[0\]}} must also occur outside the privileged block to make it easier to audit privileged code. However, {{f\[0\]}} should not leak out to untrusted code (see [SEC02-J. Guard doPrivileged blocks against untrusted invocation and leakage of sensitive data]). Minimize the amount of code that requires elevated privileges; this eases the necessary task of auditing privileged code.

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()
  //  Operations on the file using handle f[0]
  // Ensure that the file reference remains contained within changePassword()
}

Risk Assessment

Failure to follow the principle of least privilege can lead to privilege escalation.

Automated Detection

Automated checking is clearly not possible in the general case. We might be able to do something with escape analysis to check that we are not leaking privileged data provided that privileged data is marked by the user, and even that would be difficult.

Related Vulnerabilities

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

Bibliography

\[[API 2006|AA. Bibliography#API 06]\] Class {{java.security.AccessController}}
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] CWE [272|http://cwe.mitre.org/data/definitions/272.html]

System.loadLibrary("authentication");
}

The loadLibrary() invocation could also occur before preliminary password reset checks are performed; in this 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. 

Automated Detection

Bibliography

...

Image Added Image Added Image AddedSEC19-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar      Platform Security (SEC)      03. Declarations and Initialization (DCL)