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!
------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Mon Jul 30 2001 - 13:40:17 PDT