MYPROXY-2008-0005


Summary:

 

In certain circumstances, myproxy-init can run arbitrary code on the client host.


Component Vulnerable Versions Platform Availability Fix Available
myproxy-init 1.0 - 4.2 all not known to be publicly available 4.3 -
Status Access Required Host Type Required Effort Required Impact/Consequences
Verified remote ordinary user MyProxy client host medium medium
Fixed Date Credit
2008-Sep-02 Jim Kupsch

Access Required:

remote ordinary user

This vulnerability just requires a user to run myproxy-init with a a certain set of parameters.

Effort Required:

medium

This vulnerability would require a user to use an unusual set of parameters which could be accomplished using social engineering techniques.

Impact/Consequences:

medium

An attacker can run arbitrary code as the user running myproxy-init on the client host.

Full Details:

 

The command myproxy-init can uses the helper appliation grid-proxy-init or voms-proxy-init passing it user supplied data. The command to execute is a simple string that is passed to the system function. This function passes the string to the shell /bin/sh to be evaluated. If the string contains shell metacharacters such as ';' or '&&', arbitrary commands can be executed. This is called command injection.

The commands will run on the host where the user runs the client and with the same privileges as the client. This is something that a user could do normally, so it should not be a problem with a properly functioning user. Unfortunately users can tricked into running commands with arguments that may not appear to be a security problem to the user through social engineering techniques. Also if this command is run as part of a menuing system or web portal where the system is trying to limit what the user can do on the system this could be an avenue to gaining more functionality on the system.

Cause:

command injection

The cause of this vulnerability is that the function system is used without preventing command injection of meta characters.

Proposed Fix:

 

There are three ways to fix this problem: avoid using the helper application, call the helper application but avoid using system or properly quote the command string to avoid the command injection.

The best option is to use a C API if it exists as it avoids the helper application all together. This eliminates the external process and is least likely to introduce security problems..

The second best option is to use a wrapper function that performs a fork and an exec to call the helper application to avoid using the shell.

The final option is to make sure each argument to the helper application and the helper application name itself are properly quoted, then the system function can be used safely. Form the command string by concatenating the arguments together seperated by a space after they have been transformed as follows: replace all instances single quotes (') in a value with ('\''), and enclose the whole argument in single quotes. For instances the the value x's would become 'x'\''s'.

Actual Fix:

 

The proposed fix ("second best option") was implemented in MyProxy v4.3, released September 2008. The call to system in myproxy-init was replaced by calls to fork and execvp.

Acknowledgment:

 

This research funded in part by NATO grant CLG 983049, the National Science Foundation under contract with San Diego Supercomputing Center, and National Science Foundation grants CNS-0627501 and CNS-0716460.