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

Compare with Current View Page History

« Previous Version 37 Next »

Programs must comply with the principle of least privilege not only by providing privileged blocks with the minimum permissions required for correct operation, but also by ensuring that privileged blocks contain only those operations that require the increased privileges. Superfluous code contained within a privileged block necessarily operates with the privileges of that block; this increases the potential attack surface exposed to an attacker. Consequently, privileged blocks must not contain superfluous code.

Noncompliant Code Example

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

public void changePassword() {
  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 the file ...
        System.loadLibrary("LibName");
      } catch (FileNotFoundException cnf) {
        // Forward to handler
      }
      return null;
    }
  }); // end of doPrivileged()
}

This violates the principle of least privilege because a caller who does not have the required privileges may also be able to load the specified library.

Compliant Solution

This compliant solution moves the call to System.loadLibrary() outside the doPrivileged() block.

public void changePassword() {
  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);                                                     
      } catch (FileNotFoundException cnf) {
        // Forward to handler
      }
      return null;
    }
  });  // end of doPrivileged()
  // Operations on the file using handle f[0]
  // while ensuring that the f[0] reference     
  // remains contained within changePassword()
  System.loadLibrary("LibName");
}

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

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="06ef6ca6-3fc0-4358-a40f-c446b9842901"><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="7c526fa1-ad80-44f5-b493-d4f38ccd8557"><ac:plain-text-body><![CDATA[

[java:[API 2006

AA. Bibliography#API 06]]

Class java.security.AccessController

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


      14. Platform Security (SEC)      

  • No labels