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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <201409290951.s8T9pji1013992@sf01web2.securityfocus.com>
Date: Mon, 29 Sep 2014 09:51:45 GMT
From: john.fitzpatrick@...infosecurity.com
To: bugtraq@...urityfocus.com
Subject: Moab Authentication Bypass (insecure message signing) [CVE-2014-5376]

##[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