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
This archive was generated by hypermail 2b30 : Wed Apr 17 2002 - 15:46:54 PDT