This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Least Privilege Violation"
Weilin Zhong (talk | contribs) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]] | |
| + | |||
| + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| + | |||
| + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
| + | |||
| + | [[ASDR Table of Contents]] | ||
| + | __TOC__ | ||
| − | |||
==Description== | ==Description== | ||
| + | |||
| + | The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed. | ||
When a program calls a privileged function, such as chroot(), it must first acquire root privilege. As soon as the privileged operation has completed, the program should drop root privilege and return to the privilege level of the invoking user. | When a program calls a privileged function, such as chroot(), it must first acquire root privilege. As soon as the privileged operation has completed, the program should drop root privilege and return to the privilege level of the invoking user. | ||
| − | ==Examples == | + | |
| + | ==Risk Factors== | ||
| + | |||
| + | TBD | ||
| + | |||
| + | ==Examples== | ||
The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file. | The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file. | ||
| Line 26: | Line 39: | ||
| − | |||
| − | |||
| − | ==Related | + | ==Related [[Attacks]]== |
| − | + | * [[Attack 1]] | |
| + | * [[Attack 2]] | ||
| − | |||
| − | + | ==Related [[Vulnerabilities]]== | |
| − | |||
| − | + | * [[Broken Access Control]] | |
| + | * [[Failure to drop privileges when reasonable]] | ||
| − | |||
| − | == | + | ==Related [[Controls]]== |
| + | * [[:Category:Access Control]] | ||
| + | |||
| + | |||
| + | ==Related [[Technical Impacts]]== | ||
| + | |||
| + | * [[Technical Impact 1]] | ||
| + | * [[Technical Impact 2]] | ||
| + | |||
| + | |||
| + | ==References== | ||
| + | |||
| + | * [[Least privilege]] | ||
| + | |||
| + | [[Category:FIXME|add links | ||
| + | |||
| + | In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki> | ||
| + | |||
| + | Availability Vulnerability | ||
| + | |||
| + | Authorization Vulnerability | ||
| + | |||
| + | Authentication Vulnerability | ||
| + | |||
| + | Concurrency Vulnerability | ||
| + | |||
| + | Configuration Vulnerability | ||
| + | |||
| + | Cryptographic Vulnerability | ||
| + | |||
| + | Encoding Vulnerability | ||
| + | |||
| + | Error Handling Vulnerability | ||
| + | |||
| + | Input Validation Vulnerability | ||
| + | |||
| + | Logging and Auditing Vulnerability | ||
| + | |||
| + | Session Management Vulnerability]] | ||
| + | |||
| + | __NOTOC__ | ||
| + | |||
| + | |||
| + | [[Category:OWASP ASDR Project]] | ||
[[Category:Access Control Vulnerability]] | [[Category:Access Control Vulnerability]] | ||
| − | |||
[[Category:C]] | [[Category:C]] | ||
| − | |||
[[Category:Code Snippet]] | [[Category:Code Snippet]] | ||
Revision as of 18:04, 26 September 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 09/26/2008
Vulnerabilities Table of Contents
Description
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
When a program calls a privileged function, such as chroot(), it must first acquire root privilege. As soon as the privileged operation has completed, the program should drop root privilege and return to the privilege level of the invoking user.
Risk Factors
TBD
Examples
The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.
...
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...
Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
