[8263] in bugtraq

home help back first fref pref prev next nref lref last post

License Manager's lockfiles (Solaris 2.5.1)

daemon@ATHENA.MIT.EDU (Joel Eriksson)
Fri Oct 23 17:19:02 1998

Date: 	Wed, 21 Oct 1998 20:22:38 +0200
Reply-To: Joel Eriksson <na98jen@STUDENT.HIG.SE>
From: Joel Eriksson <na98jen@STUDENT.HIG.SE>
To: BUGTRAQ@NETSPACE.ORG

License Manager on Solaris 2.5.1 tends to make stupid lockfiles owned by
root and mode 666 (worldwrite'able). That is not good, since anyone could
create rootowned files which they then would be able to modify. It's an
even bigger problem since it just takes about a minute 'til the lockfile
is created after it's replaced with a symlink which it follows ..

Btw, if this is an old bug, I apologize. It's deadsimple so I would be
surprised if it's not.. :-P Well, anyway..

On the system I am on it looks like this:

bash$ ls -l /var/tmp/lock*
-rw-rw-rw-   1 root     root           0 Oct 21 18:24 /var/tmp/lockESRI
-rw-rw-rw-   1 root     root           0 Oct 21 16:40 /var/tmp/lockISE-TCADd
-rw-rw-rw-   1 root     root           0 Oct 21 14:29 /var/tmp/lockalta
-rw-rw-rw-   1 root     root           0 Oct 21 18:52 /var/tmp/lockansysd
-rw-rw-rw-   1 root     root           0 Oct 21 18:52 /var/tmp/lockasterxd
-rw-rw-rw-   1 root     root           0 Oct 21 16:40 /var/tmp/lockhpeesofd
-rw-rw-rw-   1 root     root           0 Oct 21 18:46 /var/tmp/locksuntechd

And:

bash$ ls -l /var/tmp/.flexlm
total 2
-rw-rw-rw-   1 root     root         163 Oct 21 19:55 lmgrd.211

I tested the bug by removing lockESRI and making a symlink to
/var/tmp/test, in about a minute the file was created, owned by root and
worldwrite'able.

At first I didn't know where the bug was located but managed to find out
by looking in the licenses_combined file that was passed as an option to
the programs with the lockfiles. After some research I realised that the
licenses_combined file was used by /opt/SUNWste/license_tools/lmgrd.ste
that runs on the system I'm on.

With strings I found the /usr/tmp/.flexlm (/usr/tmp is a symlink to
/var/tmp) I have not tested to symlink lmgrd.211 (211 = lmgrd.ste's PID)
but I guess it's exploitable to, if you can predict the PID (which
probably isn't that hard when it's run from rc-scripts or similar on boot)

There is also a frequent use of temporary files in the
/opt/SUNWste/license_tools/config_template which also could be a
securityrisk, at least if you can predict when the script is ran ..
Raceconditions.

/Joel Eriksson

home help back first fref pref prev next nref lref last post