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

Compare with Current View Page History

« Previous Version 31 Next »

In case of set-user-ID and set-group-ID programs, when the effective user-ID and group-ID are different from those of the real user, it is important to drop not only the user-level privileges but also the group privileges. While doing so, the order of revocation must be correct.

POSIX defines setgid() to have the following behavior [[Open Group 04]]:

If the process has appropriate privileges, setgid() shall set the real group ID, effective group ID, and the saved set-group-ID of the calling process to gid.

If the process does not have appropriate privileges, but gid is equal to the real group ID or the saved set-group-ID, setgid() shall set the effective group ID to gid; the real group ID and saved set-group-ID shall remain unchanged.

Noncompliant Code Example

This noncompliant code example drops privileges to those of the real user and similarly drops the group privileges. However, the order is incorrect because the setgid() function must be run with superuser privileges but the call to setuid() leaves the effective user ID as nonzero. As a result, if a vulnerability is discovered in the program that allows for the execution of arbitrary code, an attacker can regain the original group privileges.

/* Drop superuser privileges in incorrect order */

if (setuid(getuid()) == -1) {
  /* handle error condition */
}
if (setgid(getgid()) == -1) {
  /* handle error condition */
}

/* It is still possible to regain group privileges due to
 * incorrect relinquishment order */

Compliant Solution

This compliant solution relinquished group privileges before taking away the user-level privileges so that both operations execute as intended.

/*  Drop superuser privileges in correct order */

if (setgid(getgid()) == -1) {
  /* handle error condition */
}
if (setuid(getuid()) == -1) {
  /* handle error condition */
}

/*
 * Not possible to regain group privileges due to correct relinquishment order 
 */

Risk Assessment

Failing to observe the correct revocation order while relinquishing privileges allow an attacker to regain elevated privileges.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

POS36-C

high

probable

medium

P12

L1

Automatic Detection

Compass/ROSE can detect some violations of this rule. In particular, it warns when calls to setgid() are immediately preceded by a call to setuid().

Klocwork Version 8.0.4.16 can detect violations of this rule with the SV.FIU.PERMISSIONS and SV.USAGERULES.PERMISSIONS checkers.

Related Vulnerabilities

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

References

[[Chen 02]] "Setuid Demystified"
[[Dowd 06]] Chapter 9, "UNIX I: Privileges and Files"
[[ISO/IEC PDTR 24772]] "XYO Privilege Sandbox Issues"
[[MITRE 07]] CWE ID 696, "Incorrect Behavior Order"
[[Open Group 04]] setuid(), and setgid()


      99. The Void      

  • No labels