[CVE-2014-0749] TORQUE Buffer Overflow

[john.fitzpatrick () mwrinfosecurity com]

A buffer overflow exists in versions of TORQUE which can be exploited in order to remotely execute code from an 
unauthenticated perspective. This issue is exploitable in all versions of the 2.5 branch, upto and including 2.5.13

Software: TORQUE
Affected Versions: All 2.5 releases up to and including 2.5.13
CVE Reference: CVE-2014-0749
Authors: John Fitzpatrick (MWR Labs)
Severity: High Risk
Vendor: Adaptive Computing
Vendor Response: Incorporated MWR supplied fix into 2.5 development branch, no advisory

[Description]

A buffer overflow exists in older versions of TORQUE which can be exploited in order to remotely execute code from an 
unauthenticated perspective. This issue is exploitable in all versions of the 2.5 branch, up to and including 2.5.13.


[Impact]

Successful exploitation allows remote execution of code as root.


[Cause]

This issue exists as a result of a misplaced bounds check.


[Solution]

Despite still being widely used Torque 2.5.x is now end of life and no longer supported by Adaptive. The latest version 
of the 2.5 branch (2.5.13) is vulnerable to this issue. MWR have submitted a fix to the 2.5-dev GitHub repository 
(which is still active) which resolves this issue. It is strongly recommended that a version of 2.5-dev (later than 
pull request #171) is updated to.

Code changes in the 4.2.x branch significantly enhance the security posture of TORQUE and so MWR would recommend 
updating to this branch if possible.


[Technical Details]

TORQUE is a widely used resource manager. There are several branches 2.x, 3.x and 4.×. The code is open source, but 
maintained by Adaptive Computing.
Operations such as job submissions and querying of job queues within TORQUE are handled by the pbs_server component. It 
was found that the pbs_server did not perform sufficient bounds checking on messages sent to it. As a result it was 
found to be possible to submit messages which resulted in an overflow leading to arbitrary code execution. This could 
be achieved from a remote, unauthenticated perspective regardless of whether the source IP address is permitted to 
submit jobs or not.

The vulnerability exists because the file disrsi_.c fails to ensure that the length of count (which is read from the 
request packet) is less than dis_umaxd prior to being used in a later memcpy(). As a result a specially crafted request 
can smuggle through a count value which is later decremented and becomes the ct value in a memcpy() made from within 
tcp_gets():

memcpy((char *)str, tp->tdis_leadp, ct);

This failure to validate count allows control over the size of the memcpy() to be leveraged and as a result control 
over the amount of data read from the remainder of the packet. If this value is large the memcpy() will overwrite the 
stack and so can be leveraged in order to gain control over the execution of the program.

A backtrace showing the flow of execution is shown below:

#0 0x0000003dd4a88b9a in memcpy () from /lib64/libc.so.6
#1 0x00007fa0008cb65b in tcp_gets (fd=11, str=0x7fff8dfce741 '3' <repeats 26 times>,
"Ab1Ab2Ab3",
ct=332) at ../Libifl/tcp_dis.c:567
#2 0x00007fa0008be994 in disrsi_ (stream=11, negate=0x7fff8dfce93c, value=0x7fff8dfce938,
count=333)
at ../Libdis/disrsi_.c:187
#3 0x00007fa0008bea1a in disrsi_ (stream=11, negate=0x7fff8dfce93c, value=0x7fff8dfce938,
count=<value optimized out>) at ../Libdis/disrsi_.c:216
#4 0x00007fa0008bea1a in disrsi_ (stream=11, negate=0x7fff8dfce93c, value=0x7fff8dfce938,
count=<value optimized out>) at ../Libdis/disrsi_.c:216
#5 0x00007fa0008bdfab in disrfst (stream=11, achars=33, value=0x27f0b58 "")
at ../Libdis/disrfst.c:125
#6 0x00007fa0008c13ba in decode_DIS_ReqHdr (sock=11, preq=0x27f0b20,
proto_type=0x7fff8dfce9dc,
proto_ver=0x7fff8dfce9d8) at ../Libifl/dec_ReqHdr.c:141
#7 0x0000000000409ba1 in dis_request_read (sfds=11, request=0x27f0b20) at dis_read.c:137
#8 0x000000000041cb6e in process_request (sfds=11) at process_request.c:355
#9 0x00007fa0008d4899 in wait_request (waittime=<value optimized out>, SState=0x72c258)
at ../Libnet/net_server.c:508
#10 0x000000000041afeb in main_loop () at pbsd_main.c:1203
#11 0x000000000041bd15 in main (argc=<value optimized out>, argv=<value optimized out>)
at pbsd_main.c:1760

TORQUE is required to run as root and so successful exploitation leads to code execution as root. MWR have created a 
proof of concept exploit for TORQUE running on 64bit versions of CentOS which makes use of return oriented programming 
and ROP gadgets in order to execute arbitrary code as root. This vulnerability can be exploited reliably and remotely. 
It is possible to reach this path of execution from a remote and unauthenticated perspective (and regardless of whether 
the attackers system is in the acl_hosts list or not). It is expected that code execution within a 32bit environment is 
simpler to achieve.

Whilst the necessary bounds check was found to be missing from all versions of TORQUE reviewed this issue was only 
found to be directly exploitable in the 2.5 branch; code changes which have taken place in the 4.x branches prevent the 
condition required for exploitation from being reached. The vulnerability exists because the necessary check on the 
size of count occurs too late within the disrsi_.c file. The fix is, therefore, to introduce the appropriate check on 
the size of “count”. Replacing disrsi_.c with the patched 2.5-dev version 
(https://github.com/adaptivecomputing/torque/blob/2.5-dev/src/lib/Libdis/disrsi_.c) and recompiling should be 
sufficient to resolve this issue.


[Detailed Timeline]

2012: Vulnerability identified
06/12/2012: Proof of concept developed
22/07/2013: Vulnerability reported to Adaptive Computing
20/08/2013: MWR requested update from Adaptive
22/08/2013: Github pull request to resolve issue made by MWR with a fix
21/01/2014: Further communication with Adaptive 
13/05/2014: Advisory published


[Original Advisory]

https://labs.mwrinfosecurity.com/system/assets/662/original/torque-buffer-overflow_2014-05-14.pdf