Security Advisory

Adaptive Computing Security Advisory

Adaptive Computing Security Advisories are published for significant security issues that directly involve Adaptive Computing products and require an upgrade, fix, or other customer action. In all security advisories, Adaptive Computing discloses the minimum amount of information required for an end-user to assess the impact of a vulnerability and any potential steps needed to protect their environment. Adaptive Computing does not provide vulnerability details that could enable someone to craft an exploit. All security advisories on support.adaptivecomputing.com/security-advisory are displayed in chronological order, with the most recently updated advisory appearing at the top of the page.

November 12, 2014
Torque stack buffer overflow on disrsl_

TRQ-2971, CVE-2014-8729
There is a potential for a buffer overflow attack in the disrl_() and disrsl_() functions.

This has been fixed and is available in the 2.5-dev source code, 4.2.10, 4.5.2, and 5.0.2. Notes will be included in the respective release notes.

The two functions in question are used as part of the data in the string library, which reads and writes data across the network. With some care, a buffer overflow attack could be done for these functions, allowing malicious code to be potentially run as root.

October 6, 2014
User impersonation
MOAB-7478, MOAB-7526, CVE-2014-5375
It is possible to submit jobs to Moab as arbitrary users due to insufficient authentication checks during the submission of a job to the Moab server.

There are release notes for 7.2.9, 8.0.0 and on all subsequent releases. There was no code change for this.

Jobs submitted with invalid credentials are put in a held state, instead of rejected, until the administrator can respond. The checkjob command gives administrators further information regarding why the job is held. Blindly assuming that all held jobs should in fact be running is not only unsafe, but circumvents intentional Moab policies and workflow. An administrator should exercise care when resolving held jobs.

October 6, 2014
Insecure message signing
MOAB-7480, MOAB-7525, CVE-2014-5376
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.

There are release notes for 7.2.9, 8.0.0 and on all subsequent releases. There was no code change for this.

When installing or upgrading, it is strongly recommended that administrators configure Moab with Mauth Authentication with a complex key value.

October 6, 2014
Authentication bypass
MOAB-7479, MOAB-7524, MOAB-7100, CVE-2014-5300
It is possible to bypass authentication within Moab in order to impersonate and run commands/operations as arbitrary users. The issue is believed to affect all versions of Moab prior to versions 7.2.9 and Moab 8.

There was a code change for this which exists in 8.0.0 released, 7.2.9 released, and on all subsequent releases. There was originally no release note. Adaptive Computing updated the 8.0.0 and 7.2.9 release notes today to include a release note. There will be a similar note in subsequent releases.

October 2, 2014
Torque job can kill processes not owned by the job owner
TRQ-2885, CVE-2014-3684
After submitting a job, a non-root user can kill other processes – owned by any user – on any node running that job.

This has been fixed on 4.2.10, 4.5.1 and 5.0.1 and has been noted in the respective release notes.

Within a TORQUE Resource Manager job, the tm_adopt() TORQUE library call enables a user-built executable calling tm_adopt() to adopt any session id (and its child processes) regardless of the session id owner on any node within a job. When a job that includes the executable calling tm_adopt() exits, the adopted processes are killed along with the job processes during normal job cleanup. This can enable a non-root user to kill processes he/she doesn’t own including root-owned ones on any node in a job. The tm_adopt() function is now limited to a session id that is owned by the calling user.