COMMAND
mathlm
SYSTEMS AFFECTED
Mathematica 4.0, 4.1
PROBLEM
'Pinwheel' found following. Two not too serious bugs in the
network license manager (mathlm) for Mathematica versions 4.0 and
4.1, on at least the Intel linux platform, probably every version
and every platform. These can both lead to a denial of service
on mathlm (stopping legitimate machines from getting licenses to
run the mathematica kernel), and the latter can lead to the
granting of a mathematica license for a machine which shouldn't
be granted a license.
Roughly, the license manager (mathlm) sits and listens on port
16286, waiting for a request from a mathematica program on
another machine for a license to run the mathematica kernel.
Problem is, if a client doesn't behave nicely, the license
manager will listen all day long, and won't answer requests from
any other client -- trivial denial of service.
If the license server is called licenseserver.example.com and nc
is netcat, you can just
cat /dev/null | nc licenseserver.example.com 16286
or even
telnet licenseserver.example.com 16286
and the server won't reply to any other requests for licenses.
The restrict option for mathlm isn't invoked yet, so any
mathematica license server with port 16286 reachable from the
internet is vulnerable to a denial of service.
Mathematica License Manager Hostname Spoofing? Basically a trust
issue. The Mathematica license manager resides on a license
server, and listens to requests for licenses from mathematica
programs running on other machines on the net (call 'em clients).
Now, the way it is supposed to work is that the client sends it's
hostname and the uid of the user that mathematica is running as
(or 65536 in the case of a Windows machine) to mathlm on the
server, and it is up to mathlm to grant a license or not. Now,
the default case is that mathlm will grant a license to everyone
who asks (bad, right? Anyone can steal a license from your
machine and deprive you of what you paid for) but it does come
with an option, "-restrict anyprogramyouwant", that will run a
program of your choice, and depending on it's output, grant or
refuse to grant a license to the requesting client. More
specifically, if your restrict program returns a 1 to mathlm, a
license is granted, otherwise a license is denied.
This seems like a great idea, having the ability to restrict
access to mma licenses with any program you like (and write), but
the problem is that the mathematica client can be trivially
tricked into sending any information you want to the license
manager ... for example, the hostname of the machine mma is
running on ... meaning that any restrict program that bases it's
decision on what the client tells it (e.g. the requesting
client's hostname) can be tricked into granting a license when
one really shouldn't be granted. All you need to know is the
name of a machine that would be granted a license by the restrict
program. In trials, the name "localhost" seemed to work pretty
well.
This could also be used in a denial of service attack, since the
spoofing machine could simply request all of the available
licenses from the server.
Say a license manager is running on licenseserver.example.com, a
machine that should be granted a mma license is at
good.example.com, and a machine that should be denied a license
is at cheater.otherdomain.com.
In the case that cheater is a windows machine, simply go to the
DNS tab of the TCP/IP Properties (under network control panel, at
least on NT 4) and change the hostname to good (and maybe domain
to example.com) --- keep in mind no real DNS changes need be made
-- and run mathematica, pointing to the license server at
licenseserver.example.com. The logs on licenseserver report:
License #blah given to 65535 on host good.
and compute away.
In the case that cheater is a UNIX box, you just change the
hostname using, e.g. "hostname good.example.com", and away you
go. (Yes, you need root on client to do this, but you already
installed mathematica, right?)
SOLUTION
Well, drop packets directed to 16286 from machines you don't
trust, and hope that those you do behave nicely. Other problems
with mathlm suggest you should be filtering access to that port
in the first place.
Wolfram was notified earlier this year for this and other problems
with the license manager. They confirmed the bug and said it
would be fixed in the next version (which was 4.1). It wasn't.