a couple minor issues with mathematica license manager

[Pinwheel <pinwheel () shout net>]

Hi,

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.  There's htmlized versions at www.shout.net/~pinwheel/
if you to look at a nicer version.

Slán,

pinwheel

 ------------------------------------------------------------------------
Mathematica License Manager DoS

Affects: at least versions 4.0 and 4.1 on at least the Intel linux
 platform. Probably affects every version, but I haven't tested any other
 than the above.

Description: 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.

Code: 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.

Workaround: 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.

Notes: 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, and I wasn't going
 to bother putting this out, but I know of a site that was recently hit
 (maybe by accident), so here it is.
 ------------------------------------------------------------------------

 ------------------------------------------------------------------------
Mathematica License Manager Hostname Spoofing

Affects: At least versions 4.0 and 4.1 of mathlm running on at least the
 Intel linux platform. Probably affects all versions and platforms.
 Description: 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.

Code: 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?)

 I haven't played too much with doing things like setting MachineName in
 the mathematica program itself, but it doesn't seem too fruitful, since
 you need a license to run the mathematica kernel in the first place.
 Mathematica itself appears to use uname(2) for determining the host (errr,
 node) name.

Workaround: This can't be stressed enough ... use a firewall or some form
 of packet filtering, and drop packets destined to port 16286 from unknown
 hosts, and don't use a restrict program that relies on the information
 that the mathematica client (and thus mathlm) passes to it. Other issues
 with mathlm suggest it shouldn't be reachable from the internet anyway.
 Notes: Wolfram was notified earlier this year, verified the bug, and
 implied the problem would fixed in the new version. Well, it wasn't, but
 it isn't that serious a bug, so it's no surprise. They've been too busy
 adding more cool features to mathematica in the first place!

 ------------------------------------------------------------------------