COMMAND

	wwwisis remote command execution and get files

SYSTEMS AFFECTED

	3.x

PROBLEM

	Klaus Ripke found following regarding wwwisis,  which  runs  as  cgi  to
	query  mostly  bibliographical  databases.  Deployed  on  probably  some
	hundred systems or more. While  this  vuln  is  probably  currently  not
	being exploited,  it\'s  possible  to  install  workarounds  right  now,
	therefore this information is published.
	

	 Summary:

	 ========

	

	In common setups of wwwisis, query parameters  can  be  forged  to  have
	wwwisis execute any (shell) command and display  any  readable  file  as
	allowed for the user of the cgi process. Vulnerability  can  be  avoided
	with careful setup.
	

	

	 Description:

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

	

	Input parameters from query string are not checked  for  bad  input.  In
	common plain-vanilla setups such as the examples in the  manual,  it  is
	possible to have the process execute any format as sent  by  the  remote
	user. The formatting language has some too powerful functions. There  is
	also an alternate attack possibility abusing PATH_INFO.
	

	

	 Impact:

	 =======

	

	Ability to execute any command and get any file as allowed for  the  cgi
	process.
	

	

	 Exploits:

	 =========

	

	Since there is not yet  a  fix  published,  and  the  vuln  is  probably
	currently not being exploited, details are to follow at a later time.
	

	

SOLUTION

	 Workaround:

	 ===========

	

	Avoid wwwisis being called directly -- wrap it up in a perl  -t  script.
	Wipe out any suspicious stuff from query params, clean up the ENV,  then
	exec wwwisis with a list of params. Read the perlsec manpage.
	

	

	 Update (03 april 2002)

	 =======

	

	SOLUTION  (by  Jorge  Walters,   BIREME\'s   Coordinator   for   systems
	development)
	

	Of course the recommended action is to upgrade wwwisis to  version  5.0.
	It has been completely rebuild and incorporates a lot  of  new  features
	such as XML manipulation.
	

	For those that will not upgrade and/or need to protect legacy systems  a
	solution follows.
	

	Wwwisis 3.x versions are not longer  maintained  and  developers  should
	take care of the problem at application level following simple rules  in
	using prolog/epilog parameters.
	

	The security issue occurs only in two situations:
	

	 a) PROLOG/EPILOG parameters are set before CGI parameter in de \"somefile.in\"

	file. The solution in this case is to move them at the end  of  the  CGI
	declaration. This change should not affect program\'s logic.
	

	Example:
	

	a \"somefile.in\" file for wwwisis:
	

	

	db=/db/some

	pft=@some.pft

	prolog=@prolog.pft

	epilog=@epilog.pft

	cgi=\'bool=\',(if v100^n=\'boolean\' then v100^v fi)/

	

	

	should be changed to:
	

	

	db=/db/some

	pft=@some.pft

	cgi=\'bool=\',(if v100^n=\'boolean\' then v100^v

	fi)/,\'prolog=@prolog.pft\'/,\'epilog=@epilog.pft\'/,

	

	

	all in one line.
	

	

	 b) PROLOG/EPILOG parameters are not set.

	To create wwwisis scripts without setting prolog/epilog parameters is  a
	non common situation. In this  case,  just  declare  the  parameters  as
	\'epilog=,\' and \'prolog=,\' at the end of the CGI declaration.
	

	Example:
	

	a \"somefile.in\" file for wwwisis:
	

	

	db=/db/some

	pft=@some.pft

	cgi=\'bool=\',(if v100^n=\'boolean\' then v100^v fi)/

	

	

	should be changed to:
	

	

	db=/db/some

	pft=@some.pft

	cgi=\'bool=\',(if v100^n=\'boolean\' then v100^v fi)/,\'prolog=,\'/,\'epilog=,\'/,

	

	

	When PROLOG/EPILOG parameters are defined as indicated, there is no  way
	to break security through this trick. Even if someone  try  to  redefine
	the parameters via CGI Query.