Indiscriminate delegation of function to other systems can introduce vulnerabilities.
When a program with privileges invokes another program, unless specific steps are taken to the contrary, the invoked program will inherit the privileges of the invoker. When such invoked programs are not written with the expectation that they will execute with unusual privileges, there is an increased potential for vulnerability. Some common examples include
a "restricted" program invoking some program that itself can spawn an unrestricted shell
a setuid or setgid UNIX program invoking another command, which then executes with the setuid or setgid identity instead of the original user's identity [VU#700326, Viega 02]
Delegation to "Symbolic Link Followers"
There are probably a large number of applications that are safe with respect to traditional symlink TOCTOU defects but vulnerable to a variant [Securiteam 05]. This defect exists when one program, the privileged parent, invokes another program, the child, and:
The child is designed to be run directly by an interactive user or indirectly via a script on behalf of the user (this is correct).
The child does not need to run with more privileges than the user that invokes it (this is correct).
The child program assumes that its invoker trusts all files that are specified as arguments (this is correct).
The child program follows symlinks (this is correct; it is the point of symbolic links).
The parent delegates an operation to the child with parent's privileges, passing filenames as arguments (this is not correct).
The files named in the filenames passed by the parent are
controllable, or predictable, by the adversary, and
in a directory that's writable by the adversary.
The attacker can use a conventional symlink attack on the filename arguments that the parent passes to the child.
The security vulnerability lies in step 6. It is the parent's responsibility to protect against this; changing the child could sits normal function.
Compared to conventional symlinks attacks, the attack here need not involve temporary files.
All of the following must be true:
The invoking program must be operating with unusual privileges.
The invoking program must spawn another program to perform some function on its behalf.
The spawned program must not expect to have been invoked with other than normal privileges.
Impacts Being Mitigated
Minimally: The minimal impact is nothing. Programs invoked by a privileged program may not perform any action that makes the delegation vulnerable.
Maximally: The maximal impact can be significant or even ultimate. If the invoked program can be influenced by the adversary to take some action from which the adversary will benefit, that action is the maximal impact of the delegation failure.
Security Policies to be Preserved
The programmer who delegates some action to another program may be unaware of the security policy being implemented by the combination.
How to Recognize this Defect
Look for operations that spawn subprocesses and determine if the invoked program is invoked with unexpected privileges.
Audit the invoked program to make sure that it cannot perform any action that violates the expected security policy.
Set the invoking program's privileges back to normal before invoking a child program.
Eliminate the delegation, typically by incorporating the required function of the delegated program into the invoking program.
Bishop, M. “How To Write A Setuid Program.” ;login: 12, 1 (January/February 1987): 5-11.
Beyond Security: SecuriTeam. Second-Order Symlink Vulnerabilities. June, 20, 2005. http://www.securiteam.com/securityreviews/5FP0L00G1E.html.
|[Viega 02]||Viega, John & McGraw, Gary. Building Secure Software: How to Avoid Security Problems the Right Way. Boston, MA: Addison-Wesley, 2002.|
Dormann, Will. Vulnerability Note VU#700326: cdrecord fails to set proper permissions on programs specified in RSH environment variable. cert.org, 09/17/2004. http://www.kb.cert.org/vuls/id/700326.
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at firstname.lastname@example.org.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.