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