Re: solaris 2.4 license-manager bug

[jhoward () agso gov au (Jeffrey Howard)]

> > > Another bug for solaris 2.4
> > > The license manager must be running, expect both
> > > lmgrd.ste & suntechd to be somewhere in your process table.
>
> ...
>
> > Some observations ...
> >
> > Lock files are created by the lmgrd process for each license daemon
> > process it manages when it starts. These lock files are generally owned
> > by root, the id under which they were started. If the sticky bit is set
> > on the /var/tmp directory, no normal user will be able to remove the
> > lock file, thus breaking step 1 of the exploit.
> >
> > Perhaps there is a window of opportunity if you can create the symbolic
> > ....

Lots of replies to my followup to gkaufman's orginal post on this
subject. I thought I would send a summary back to the list FYI.

Most pointed out that if the licence manager's lock files are created
with 666 permissions, the sticky bit doesn't help much in preventing
normal user's from screwing with root created files. My original
followup only considered the case where umask was used to ensure that
the lock files were created 644.

I also got a pointer from AUSCERT to

        ftp://ftp.auscert.org.au/pub/auscert/advisory/
                AA-96.03.Multi-platform.Unix.FLEXlm.Vulnerabilities

This advisory deals with the use of umask to prevent 666 lock files
from flexlm, and also says that flexlm doesn't need root priviledges so
it should be kicked off under some other uid, perferably an account
created for the purpose. There is also a version 5.0b of flexlm which
was created to fix an unmentioned (symbolic links?) security hole
introduced in version 4.0 and present up until version 5.0a. It
suggested that everyone should upgrade to this version of flexlm,
avaliable through

        http://www.globetrotter.com/lmgrd.htm

Thanks for all the info. Subject closed?

---
Cheers, Jeff        jhoward () agso gov au