Vulnerability Development mailing list archives

Buffer overflow vulnerability in action argument of dtaction


From: <bknight () iland co kr>
Date: Tue, 16 Oct 2001 06:57:24 +0900 (KST)


r0ar Security Advisory
October 5, 2001

Buffer overflow vulnerability in action argument of dtaction

Desription

The dtaction utility allows applications or shell scripts, which are
otherwise not connected into the CDE development environment, to invoke
action requests. The action called action_name is invoked with the action_arg
provided on the command line. A single action_name is required; the user
may provide any number of action_args. Whereas the buffer overflow is
occurred when an action_arg has more than 1023 characters.


Impact

We concluded this vulnerability is not local root compromise on our SunOS
5.8 (x86) machine.However, dtaction have root suid and sys sgid permissions.
Thus this vulnerability should be examined rigorously on other systems.


Workaround

If root suid or sys sgid permission is not needed, remove suid and sgid
bits.


Tested systems

SunOS 5.8 (x86), SunOS 5.6 (sparc)


Background

We confirmed the buffer overflow vulnerability of action_arg
in /usr/dt/bin/dtaction as following procedure.

$ DISPLAY="127.0.0.1:0.0"
$ export DISPLAY
$ /usr/dt/bin/dtaction foo `perl -e 'print "A"x1023'`
Segmentation Fault
$ ls -l /usr/dt/bin/dtaction
-r-sr-sr-x   1 root     sys        22496 Dec  2  1999 /usr/dt/bin/dtaction
$ uname -svrm
SunOS 5.8 Generic_108529-10 i86pc

Thus, the stack layout for action_arg is investigated and shown in the
following diagram.

[   Buffer  ] Offset 0000-1022
[ Saved ebp ] Offset 1023-1026
[ Saved eip ] Offset 1027-1029
[ Saved edi ] Offset 1027-1030
[ Saved eax ] Offset 1031-1034
[ Saved edx ] Offset 1044-1047

From the result of analysis of dumped core, we found that dtaction uses
strcpy and then strcat to move action_arg to stack region and strcat
function call from libDtSvc library causes buffer overflow.

(gdb) where
#0  0xdf7ecffc in strcpy () from /usr/lib/libc.so.1
#1  0xdfb4a8a3 in Xestrcpy () from /usr/dt/lib/libDtSvc.so.1
#2  0xdfb5189f in CreateInvocationRecord () from /usr/dt/lib/libDtSvc.so.1
#3  0xdfb4fd76 in DtActionInvoke () from /usr/dt/lib/libDtSvc.so.1
#4  0x80523f2 in main ()
#5  0x8052074 in _start ()

** snip **

(gdb) where
#0  0xdf80e360 in strcat () from /usr/lib/libc.so.1
#1  0xdfb4af32 in Xestrcat () from /usr/dt/lib/libDtSvc.so.1
#2  0xdfb564a4 in _DtActMapFileName () from /usr/dt/lib/libDtSvc.so.1
#3  0xdfb561d0 in LinkToTypeQuark () from /usr/dt/lib/libDtSvc.so.1
#4  0xdfb56191 in TryToTypeFile () from /usr/dt/lib/libDtSvc.so.1
#5  0xdfb55f91 in ParseFileArgument () from /usr/dt/lib/libDtSvc.so.1
#6  0xdfb51ad2 in CreateActionRequest () from /usr/dt/lib/libDtSvc.so.1
#7  0xdfb4fde6 in DtActionInvoke () from /usr/dt/lib/libDtSvc.so.1
#8  0x80523f2 in main ()
#9  0x8052074 in _start ()

From above diagram, we can't overwrite all return address. So, we tried
the frame pointer overwrite technique to exploit dtaction. However, we can
get only normal user shell because the setuid(0) function call in the
shellcode is failed. Thus we concluded this vulnerability is not local root
compromise but should be rigorously investigated.

Thanks to r0ar members and UNYUN for his valuable discussion and
shellcode.

---
http://www.r0ar.org (formely known as ksecurity)

e-mail : bknight () r0ar org




Current thread: