IBM Informix Web DataBlade: Local root by design

[Simon Lodal <simonl () mirrormind com>]

IBM Informix Web DataBlade: Local root by design

By Simon Lodal, Denmark
Vendor status: Notified months ago, said they would be working on
updates, never heard anything.
Software: Web DataBlade 4.12, IDS 9.20/9.21, Linux 2.2/2.4, SunOS 5.7
(OS, IDS and WDB versions seem to be irrelevant).

Impact: Any user who can: 1) Save a Perl script anywhere on the server's
disk, 2) Run WebDataBlade HTML code of his own choice (calling that Perl
script) ... can execute any code of choice as the database uid, which is
usually root. Any WDB developer can do this. Any other local user with
admin right on any database can do it by loading the WDB module into
their database. Other local users will not be able to exploit this by
default, but if just one WDB developer has lax permissions on his
scripts, other users may modify it to assign root access to themselves.
Finally, the SQL injection vulnerability (other report) allows any
remote user to save Perl script and execute it from HTML code. These
vulnerabilities can therefore be combined into a remote root exploit.

Workaround: Disable the entire Perl script feature. I believe it must be
enabled explicitly, but that may depend on how you got Web DataBlade.
However, any site needing to send mail, copy/move/create/delete external
files, or otherwise communicate with the world outside the database,
will usually need to use this feature, as it is the easiest way to do
these things (alternatives are C and Java).


-------
Details

The Web DataBlade has an unrestricted facility for running commands of
choice as the database user. The database runs as root, unless you have
taken special precautions to start it as another user. Therefore you get
root, by design. Or at least "informix", if the administrator managed to
start the database as this user.

The Web DataBlade language has no builtin commands for dealing with
files, network etc. Instead, Informix allows calling external scripts.
Such a feature, you would think, would simply allow execution of shell
commands, like system(). But Informix decided a much more complex setup
using a long-running daemon written in Perl. You can not call shell
commands from the HTML pages, instead pages instructs the daemon to
execute a labeled piece of (Perl) code; a "meta" function. The Perl
daemon is connected through a socket connection. The daemon is started
the first time a function in it is called, and keeps running until the
database itself is shutdown.

This design may look nice. Some actions can be done with Perl code
alone, avoiding spawning a new process and thus potentially gaining
speed. Too, it limits what commands can be run; this is decided by the
person who has access to change the Perl script. And it can take some
complexity away from the HTML code.

But now the trouble. Anyone with write access to somewhere on the
server's disk can add his own Perl script. Anybody who can add WDB HTML
code request his own page and thus call the script and the functions
within it. Several different Perl daemons can run simultaneously, and
there are no restrictions on where the scripts should be placed, who can
call the actions within them, who should own them or what their
permissions should be.

All this would not be so bad, if the script were just run as
stand-alone, one-shot shell commands, running under the uid of the
calling user. But the scripts are started by the database, and keep
running as the database user (again, usually root), regardless of
caller's identity. Simply said, you can create a Perl script of choice
and have it run as root.

Unfortunately this is an utter design mistake which can not easily be
fixed, at least not without breaking existing scripts. The Webdriver
module usually logs into the database using one specific
username/password, but it can also be configured to login on behalf of
the actual user making the connection to the webserver. This would not
be a problem if external commands were executed as separate processes
running under the uid of the connecting user, but here we are dealing
with a daemon executing commands on behalf of possibly many different
uids (any uid which the webdriver can connect as). And in their infinite
wisdom Informix decided that when we dont know which uid we will serve,
they'll better just get the uid of the database server itself, which
usually happens to be root. They simply did not even think about how to
deal with the change of uids. A brief discussion I had with a developer
at Informix clearly indicated complete lack of understanding of this
problem.

As a sidenote, Informix' own example script contains an action which is
intended to allow execution of user-defined Perl code...

Proof of concept: I am not going to provide the exact syntax here since
that does not help the description any further. Anyone with access to a
machine running WDB can fetch the example script and modify it. Try fx
to write a new file, and see who gets to own it.


Simon Lodal