MYPROXY-2008-0001

A user from a remote host that is able to just connect to a myproxy-server can cause reduced availability of the myproxy-server.

remote user able to connect to MyProxy server

This vulnerability requires a user to be able to connect to the myproxy-server and does not require being able to authenticate to the MyProxy server.

medium

To exploit this vulnerability requires a modified client.

low

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

There are two causes of denial of server in the way myproxy-server handles reading data from a client. These are due to lack of timeouts and limits on the total amount of data read.

The lack of timeouts on reads and writes, such as in read_all, can be exploited in a modified client by having it not write the expected amount of data. The server will try to read the expected amount of data without a timeout and will block until it receives all the data expected. The myproxy-server child will then be waiting forever. This will cause the server host to consume operating system resources (a process, memory, network socket, etc.). Since there is no limit to the number of spawned child myproxy-server's, this can be used to eventually cause some operating system limit to be reached.

The second problem is that there is no limit to the amount of data the server is willing to read from the client. This can lead to resource exhaustion more quickly and can be used in conjunction with lack of timeouts to have the waiting processes consuming a large amount of memory.

This problem occurs in the read_token function. The function determines end of message when there is no more data immediately available on the socket after reading a TLS packet. The client can always transmit data so a new TLS header is included with the last bit of the previous packet so this is always true. This is also problematic in that a legitimate multi-TLS packet message could be truncated if a TLS packet boundary coincides with a TCP packet boundary and the second packet is delayed. The code loops and appends the next TLS packet's data to the current buffer expanding the buffer using realloc. Besides memory, CPU can also be consumed if the realloc causes a large buffer to be copied.

denial of service

This vulnerability is caused by lack of timeouts for I/O operations and failure to limit the amount of data read.

A reasonable timeout should be set for all reads and writes between the client and server. The child myproxy-server process should exit with an error if the message is not sent or received in time. This can be accomplished using the select function in conjunction with the read or write.

Also a reasonable limit to the amount of data read in a message should be enforced, and an error produces if the limit is met. Ideally the size of a MyProxy message would be placed in a header before the data is sent, so the server knows how much data to read and can reject the request without reading any more data. Otherwise the read_token function needs to incrementally decrypt the message and be aware of where the MyProxy message boundary is.

The proposed fixes were implemented in MyProxy v4.3, released September 2008. A default timeout of 120 seconds is set for myproxy-server child processes to service requests before aborting, customizable via the myproxy-server.config request_timeout parameter, and a 1MB maximum is enforced for incoming messages to avoid memory exhaustion under heavy load.

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.