COMMAND
	IBM Informix Web DataBlade local root by design
SYSTEMS AFFECTED
	Web DataBlade 4.12, IDS 9.20/9.21, Linux 2.2/2.4, SunOS 5.7
PROBLEM
	Simon Lodal says :
	 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.
	 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.
SOLUTION
	 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).