[NEWS] IBM Informix Web DataBlade Local Root by Design

From: support@securiteam.com
Date: 04/18/02


From: support@securiteam.com
To: list@securiteam.com
Date: Thu, 18 Apr 2002 22:06:28 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  IBM Informix Web DataBlade Local Root by Design
------------------------------------------------------------------------

SUMMARY

The <http://www-4.ibm.com/software/data/informix/blades/web/> Informix
Web DataBlade module is a collection of tools, functions, and examples
that ease development of "intelligent", interactive, Web-enabled database
applications. The Web DataBlade module supports most Web Server
Application Programming Interfaces (APIs), and enables a truly interactive
Web site. A security vulnerability in the product allows attackers to run
perl script with the security context of the database user (usually
'root'), allowing them to compromise the remote operating system's
security.

DETAILS

Vulnerable systems:
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).

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

The Web DataBlade language has no built-in commands for dealing with
files, network etc. Instead, Informix allows calling of external scripts.
Such a feature, you would think, would simply allow execution of shell
commands, like system(). This is not the case of DataBlade, Informix
decided to implement a much more complex setup using a daemon written in
Perl. You cannot 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 gaining optimization speed.
Moreover, it limits what commands can be run; this is decided by the
person who has access to change the Perl script. In addition, it can take
some complexity away from the HTML code.

But this is where the trouble begins. Anyone with write access to anywhere
on the server's disk can add his own Perl script. Anybody who can add WDB
HTML code can 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.

Not all this would be so bad, if the script were just run as stand-alone,
one-time shell commands, running under the uid of the calling user.
However, 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 utter design mistake cannot 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 web server. 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 that the webdriver can connect
as). Therefore, Informix decided that when we do not know what uid we will
serve, we will better just get the uid of the database server itself,
which usually happens to be 'root'.

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

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
administrator 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.

ADDITIONAL INFORMATION

The information has been provided by <mailto:simonl@mirrormind.com> Simon
Lodal.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages

  • Re: Slow Performance When Using DBI, otherwise Not
    ... If I run the same perl script on the database server itself it runs ... check versions of DBI and DBD (I greped for version on every module under ...
    (perl.dbi.users)
  • Re: Database utilities
    ... One can write and execute a script like the one below ... The script would not actually be executed by the text editor, ... > databases using database tools and utilities. ... I think that perormance is not a typical security matter. ...
    (microsoft.public.sqlserver.security)
  • Re: Database utilities
    ... text editor and execute using standard OS componenets". ... > I think that perormance is not a typical security matter. ... SQL script and the script is run by the app immediately after each database ...
    (microsoft.public.sqlserver.security)
  • RE: Cant call method "prepare" on an undefined value
    ... The error happen on the line to connect to that database: ... This script is working fine I located the script in same server as the ... I have one oracle database located at server A and setup the Oracle ... When I run the perl script, ...
    (perl.dbi.users)
  • Re: Bypass Security Warnings in Access Runtime
    ... > security to low. ... sets the macro security level to low for that single invocation of ... by that script. ... o.opencurrentdatabase "full path to your database" ...
    (microsoft.public.access.security)