6818322 2001-07-30 14:44 -0500 /133 rader/ Pinwheel <pinwheel@shout.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-30 22:55 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18518>
Ärende: a couple minor issues with mathematica license manager
------------------------------------------------------------
From: Pinwheel <pinwheel@shout.net>
To: bugtraq@securityfocus.com
Message-ID: <20010730144420.B8901@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!
------------------------------------------------------------------------
(6818322) /Pinwheel <pinwheel@shout.net>/-(Ombruten)
Kommentar i text 6818386