Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2022.2

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 blocks contain 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; this increases , increasing the potential attack surface exposed to an attacker. Consequently, privileged blocks must not contain superfluous code.

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.

Code Block
bgColor#FFcccc

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);                                                     
        // Operate 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 example violates the principle of least privilege because a caller who does not have the required privileges may also be able to load the specified librarybecause 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. 

Code Block
bgColor#ccccff

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]
  // while ensuring that the f[0] reference     
  // remains contained within changePassword()
  System.loadLibrary("LibNameauthentication");
}

Wiki Markup
The open {{FileInputStream f\[java:0\]}} must not allow {{f\[java:0\]}} to escape out of {{changePassword()}} (see [java:SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary]). 

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 Minimizing the amount of code that requires elevated privileges eases the necessary task of auditing privileged code. 

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC02-J

high

probable

high

P6

L2

Automated Detection

Automated checking is not possible in the general case. Escape analysis might be used to check that privileged data is not leaked provided that privileged data is indicated by the user.

Related Guidelines

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e5cb0ee9-6e95-4688-aad7-ae7b3402dcda"><ac:plain-text-body><![CDATA[

[ISO/IEC TR 24772:2010

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

"Privilege Sandbox Issues [java:XYO]"

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

MITRE CWE

CWE ID 272, "Least Privilege Violation"

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="25d59a79-1425-4bbe-ae6f-8f43d2c8205f"><ac:plain-text-body><![CDATA[

[java:[API 2006

AA. Bibliography#API 06]]

Class java.security.AccessController

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

Automated Detection

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.SEC51.PCLLimit the number of lines in "privileged" code blocks

Bibliography


...

Image Added Image Added Image Removed      14. Platform Security (SEC)      Image Modified