#######################################################################

                             Luigi Auriemma

Application:  FlexNet License Server Manager
              http://www.flexerasoftware.com/products/flexnet-publisher.htm
              http://www.globes.com
Versions:     <= 11.9 and others earlier (this version number was
              written when I found the advisory many months/years ago)
Platforms:    AIX, HP-UX, Linux, Mac OSX, Windows, SGI, Solaris
Bug:          arbitrary system commands execution
Exploitation: remote, versus server
Date:         found     25 Oct 2010
              fixed     28 Jul 2011
              advisory  13 May 2012
Author:       Luigi Auriemma
              e-mail: aluigi@autistici.org
              web:    aluigi.org


#######################################################################


1) Introduction
2) Bug
3) The Code
4) Fix


#######################################################################

===============
1) Introduction
===============


"FlexNet Publisher software licensing makes it easy for software
vendors and high-tech manufacturers to manage, secure, enhance, and
grow market share through flexible pricing, packaging, licensing, and
protection of their software and SaaS offerings."


#######################################################################

======
2) Bug
======


lmadmin and lmgrd are two license server managers listening on port
27000 and usually running as system services in the products of various
vendors like IBM, HP, Sybase, Citrix, VMWare, SolidWorks and so on.
The only difference between the two servers is that lmadmin includes
a web interface from which it can be configured and managed.

The architecture for handling the licenses is composed by one or more
license servers (lmadmin/lmgrd), the vendor daemon that "keeps track of
the number of licenses checked out and who has each license by
accessing memory and granting or denying license checkouts" and the
application program that "communicates with the vendor daemon to
request a license for check out".

The problem is a mix of some design and security errors that can be
resumed in the following list:
- it's possible to change the names of the logs of both the license and
  vendor servers
- no authentication is required to do it (only one packet)
- it's possible to specify directory traversal and even absolute and
  UNC paths
- the logs are stored exactly as they come from the source without the
  filtering of bad chars (like 0x0a)

In short an attacker can easily change the location of some logs and
choosing their names, injecting data in them and then restoring the
old location or another one so that he can execute arbitrary system
commands.
For example he can create a file.bat in the Startup folder of the
Administrator (the servers usually run as services so there is no
problem of permissions) that creates a new user with administrator
privileges or downloading a backdoor when the server restarts or when
the Administrator logins and any other possible scenario in the fantasy
of the attacker.
Obviously the same is valid also for the other non-Windows platforms.

The best way I have found for exploiting this vulnerability is through
the setting of the log of the vendor daemon, that normally is done
through the command
"lmutil lmswitch -c license.lic VENDOR_NAME new_log.log" that uses
the packet type 'w' which can be used also for the injection part.

So the command must be sent directly to the vendor daemon that listens
on the first free port but luckily its port can be identified through a
simple scanning since returns a 'W' followed by a number like "W.-60"
when receives invalid data or a wrong checkum.
Another way to know the port is simply querying directly the license
server which is very "verbose" of informations included a 16bit field
with such port, so it's really easy.


#######################################################################

===========
3) The Code
===========


http://aluigi.org/poc/fnplm_2.dat

  nc SERVER PORT < fnplm_2.dat

where PORT is the one of the vendor daemon (the child process started
by lmadmin/lmgrd).


#######################################################################

======
4) Fix
======


Fixed.


#######################################################################