Page History

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 and supplemental group privileges. While doing so, the order of revocation must be correct.

...

This non-compliant code example drops privileges to those of the real user and similarly also accounts for dropping the group privileges. However, the specified order is incorrect as the call to setuid() will leave the effective UID user ID as non zero. The setgid() system call in the next line should be run with superuser privileges, however, this call fails to behave as expected since the effective user ID is no longer that of the superuser (now non zero after the privilege drop in the previous line). In effect, if another flaw that allows execution of a setegid(0) or a setregid(-1,0) is found in the program, the attacker can regain the original group privileges because setgid(getgid()) tends to leave the saved set-group-ID intact under the conditions discussed.

/* 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

Relinquish 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

This rule captures avoidable mistakes which may otherwise lead to a false sense of code security and unintended privilege escalation.

...