COMMAND

	Oracle listener may be fooled to run commands, potential remote access

SYSTEMS AFFECTED

	Oracle 8, 9 on all operating systems

PROBLEM

	In     David     Litchfield     [http://www.nextgenss.com]      adivsory
	[#NISR06022002A] :
	

	Attackers can execute any function in any library remotely on  a  system
	running Oracle\'s database server without a user ID or password.
	

	A large part of Oracle database  functionality  is  provided  by  PL/SQL
	packages. PL/SQL, or Procedural  Language/  Structured  Query  Language,
	extends SQL  and  allows  an  \"executable\"  package  be  created  that
	exports procedures and functions. PL/SQL packages  can  be  extended  to
	call functions exported by operating system libraries  or  Dynamic  Link
	Libraries. It is possible  to  create  a  (PL/SQL)  library  and  PL/SQL
	package that calls any function in any library on the  file  system.  An
	attack would probably call system() and pass the name of  a  program  to
	be executed. It is apparent that to do this  a  user  must  be  able  to
	connect to the Oracle database server and login  with  an  account  that
	has the CREATE LIBRARY permission before an attack  becomes  successful.
	However, NGSSoftware Insight Security Research has discovered a  way  to
	fool the Oracle database server into  loading  arbitrary  libraries  and
	executing arbitrary functions without ever having to authenticate.
	

	When a PL/SQL package executing in the database is required  to  run  an
	external procedure the oracle  process  connects  to  the  Listener  and
	requests that the Listener load the relevant library, call the  function
	and pass the function any parameters passed to  it.  The  Listener  does
	not load the library into its  own  process  address  space  but  rather
	launches another process, extproc on  Unix  systems  or  extproc.exe  on
	Windows platforms, and directs oracle to connect to it.  Oracle  obliges
	and connects to the extproc process using  named  pipes  and  makes  the
	same request that it made to the listener.  Extproc  loads  the  library
	and calls the function. There is no  authentication  performed  anywhere
	in all of  this.  This  opens  up  a  glaring  and  extremely  dangerous
	security hole.
	

	It is possible for an attacker to masquerade as an  Oracle  process  and
	execute any function in any DLL on the  file  system.  What  exacerbates
	this problem is that,  even  though  communication  normally  goes  over
	named pipes, it can be forced to use sockets and can be  done  remotely.
	Because of this, an attacker can write an exploit that connects  to  the
	listener/extproc over TCP and, without ever having to authenticate,  run
	any function in any  library  they  wish.  A  real  world  attack  would
	probably call system() exported by msvcrt.dll on  Windows  platforms  or
	exec() or system() exported by libc on  unix  platforms.  Any  operating
	system command passed as a parameter to these  functions  would  run  in
	the security context of the account running  the  oracle  processes.  On
	Unix systems this  is  commonly  the  \"oracle\"  user  and  on  Windows
	NT/2000 this is, by default, the local SYSTEM account. Needless  to  say
	that any commands executed as these users will  have  dire  consequences
	for the computer system involved.

SOLUTION

	There are several things that can be done to help mitigate the  risk  of
	such an attack. The first line of defense is, of course,  with  the  use
	of a firewall. No one should be able to  access  the  listener  port  of
	1521 from the Internet. This not only helps mitigate the risk  concerned
	with this problem but a slew of others, too.
	

	Moving to the Oracle database server  itself,  PLSExtproc  functionality
	can be removed if not needed. To do this remove the relevant entries  in
	tnsnames.ora and listener.ora. The PLS External  Procedure  service  can
	have many different names depending upon the system and  Oracle  version
	installed. This could be icache_extproc, PLSExtproc or  extproc.  It  is
	also suggested that extproc(.exe) be deleted, too,  on  the  off  chance
	that  an  attacker,   replaces   the   entries   in   tnsnames.ora   and
	listener.ora.
	

	If this functionality is required then  it  is  possible  to  limit  the
	machines that may access the listener. Whilst this is a trust  mechanism
	based only on IP address it does help. The  process  is  called  \"valid
	node checking\" and requires  a  modification  to  the  sqlnet.ora  file
	found in the $ORACLE_HOME\\network\\admin directory. Add the entries
	

	 tcp.validnode_checking = YES

	 tcp.invited_nodes = (10.1.1.2, scylla)

	

	Replace 10.1.1.2 or Scylla in this example with the hosts  that  require
	access. Any host not listed here will  still  be  able  to  make  a  TCP
	connection to the listener but the listener will  simply  terminate  the
	connection. Invited nodes should be restricted to machines that  require
	access.
	

	As another step towards help mitigating the  risk,  you  could  set  the
	listener listening on a non-default port (i.e. not  1521).  Whilst  this
	is not a great solution, as anyone with a TCP port scanner has a  highly
	likely chance of finding the listener, it still helps.
	

	Finally, on Windows NT/2000 the Oracle processes should not  be  running
	as local SYSTEM. It is  suggested  that  a  low  privileged  account  be
	created and the Oracle processes run as this  user.  This  account  will
	need to be given the \"Logon as a service\" account privilege.