Bugtraq mailing list archives

Moab Authentication Bypass (insecure message signing) [CVE-2014-5376]


From: john.fitzpatrick () mwrinfosecurity com
Date: Mon, 29 Sep 2014 09:51:45 GMT

##[Moab Authentication Bypass (insecure message signing) : CVE-2014-5376]##

Software: Moab
Affected Versions: Dependent on configuration, can affect all versions of Moab including Moab 8
CVE Reference: CVE-2014-5376
Author: John Fitzpatrick, Luke Jennings MWR Labs (http://labs.mwrinfosecurity.com/)
Severity: High Risk
Vendor: Adaptive Computing
Vendor Response: Provided additional guidance in 7.2.9 release notes (MOAB-7480) 


##[Description]
Moab provides two methods to authenticate messages sent by users (e.g. job submissions). The default scheme which is 
widely used is insecure and can be circumvented in order to impersonate other users and perform operations on their 
behalf.


##[Impact]

It is possible to exploit this issue remotely in order to perform any operation on the server from the perspective of 
any user role. Examples include submitting jobs as arbitrary users (including as root), as well as reconfiguring the 
Moab server itself.


##[Cause]

The default authentication mechanism does not perform sufficient validation that the user requesting the signing of a 
message is the owner of the message.


##[Solution]

Make use of moab.key files with a complex key value.

Adaptive acknowledge this issue in the 7.2.9 release notes (MOAB-7480) as a known issue, stating:

"When installing or upgrading, it is strongly recommended that administrators configure Moab with mauth authentication 
with a complex key value. See Mauth Authentication 
(http://docs.adaptivecomputing.com/mwm/7-2-9/help.htm#a.esecurity.html%23mauth) for more information."


##[Technical Details]

Moab is a workload manager used in High Performance Computing (HPC) environments. In a typical environment a user 
submits their jobs to the Moab server for it to handle the workload. Moab communication makes use of an XML based 
protocol and these messages are signed with a key. An example message is shown below:

<Envelope component="ClusterScheduler" count="1" name="moab" type="nonblocking" version="8.0.beta.2">
  <Signature>
    <DigestValue>7v49VzAlbyNQ4O3VChCus+v2LeE=</DigestValue>
    <SignatureValue>QG13cmxhYnMgRWFzdGVyIEVnZyE=</SignatureValue>
  </Signature>
  <Body actor="test" timestamp="1408488412">
    <Request action="submit" actor="test" cmdline="\STARTmsub">
      <Object>job</Object>
      <job>
        <Owner>test</Owner>
        <UserId>test</UserId>
        <GroupId>test</GroupId>
        <InitialWorkingDirectory>/home/test</InitialWorkingDirectory>
        <UMask>2</UMask>
        <Executable>/usr/bin/id</Executable>
        <SubmitLanguage>PBS</SubmitLanguage>
        <SubmitString>\START/usr/bin/id\0a\0a</SubmitString>
      </job>
    </Request>
  </Body>
</Envelope>

On receiving a message the server will generate a signature and ensure that it matches the <SignatureValue> element 
within the message. This signature is effectively computed in the following manner:

signature = f(messageBody,key)

Therefore in order to communicate with the Moab server users must be able to compute valid signatures and two 
mechanisms are provided within Moab for achieving this:

1. The use of .moab.key files (more secure)
2. Use of a pre-generated key (insecure) - default

Where .moab.key files are used a SUID root binary (mauth) provides an interface to this key as well as a means for 
verifying that the user calling mauth matches the actor specified within the XML message being signed.

Where a pre-generated key is used mauth is not called and the generation of messages is performed entirely within the 
context of the calling user. There is no validation that the user requesting the signing of the message is the actor 
specified within the message. As a result where pre-generated keys are used it is possible to craft messages belonging 
to other users and to perform operations and submit jobs as other users. Simply patching the return value of calls to 
getuid() is sufficient to impersonate other users. 


##[Detailed Timeline]

2014-01-21 : Detailed vulnerability information provided to Adaptive 
2014-08-27 : Full advisory provided to Adaptive
2014-09-08 : Release of advisory to HPC community
2014-09-25 : Public release of advisory

http://labs.mwrinfosecurity.com


Current thread: