MYPROXY-2008-0002

A user from a remote host that is able to connect and authenticate to a myproxy-server can cause reduced availability of the myproxy-server under certain configurations.

remote user with a MyProxy authorization

This vulnerability requires a user to be able to connect and authenticate to the myproxy-server.

high

To exploit this vulnerability requires a client with carefully crafted set of parameters and a particular configuration.

low

This vulnerability can result in reduced availability of the myproxy-server.

In certain configurations, MyProxy allows external executables to be called. These are called using a function myproxy_popen. This function takes an array of 3 file descriptors and a set of parameters identical to execl except the command name is duplicated into argv[0]. This function does not have the shell injection problem of popen, since it does not use the shell to evaluate the string. The function returns the status of the exec. The application must manually handle waiting for the process to exit and to handle the stdin, stdout and stderr file descriptors connected to the external process.

The idiom for using this function is to call it, write all the input if any to the new process's stdin file descriptor, and then close the process's stdin file descriptor. The next step in the idiom is to wait for the process to exit. After this all the data from the process's stdout file descriptor is read followed by the data from the stderr file descriptor.

If the process writes more than some operating defined limit, which can be as small as 512 bytes, the myproxy-server and the child helper application will dead lock as the child will block writing on the reader, but the myproxy-server will not read any data to free space until the child exits.

This deadlocked pair of processes can lead to resource exhaustion on the myproxy-server host, which can eventually lead to the myproxy-server application or host to become unresponsive.

denial of service

This vulnerability is caused by using blocking I/O to handle multiple simultaneous I/O connections between processes, which can lead to deadlock.

The idiom to execute the helper application, exec, write to stdin, wait for the process to exit, and then read the data from stdout and stderr should be replaced by a new function new_popen. This function should conceptually have the following interface:

int new_popen(const char *in, char **out, char **err, char *cmd, ...)

This function should encapsulate the entire the lifetime of the helper application from start to finish. The function should return the status of the exec, and a buffer containing the stdout and stderr of the helper application. Internally it should exec the process as before, but should then use a select loop to write the data to stdin and read the data from stdout and stderr. Using select to simultaneously handle the three file descriptors will avoid the deadlock and can also be used to provide an appropriate timeout.

The MyProxy project has no plans to fix this possible deadlock condition unless and until it is found to be a problem in practice.

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.