telnet hole.txt

当今

发信人: biff (大可), 信区: Security 
标  题: telnet hole 
发信站: 武汉白云黄鹤站 (Sun Jun 13 14:56:27 1999), 站内信件 
  
  
INTRODUCTION: 
Gday. This tar file contains a number of files that will allow you 
to get root access to between 40% to 70% of all Unix machines. 
  
  
  
telnetd_exploit.tar.gz 
  
  
  
  
It does this by exploiting a hole/feature in telnetd where environment 
variables are passed from the calling telnet client, to the recieving telnet 
daemon. These are normal env variables, such as TERM and TZ. However, there 
are a few which affect the runtime linker/loader (ld.so). These variables 
affect how ld.so finds and uses shared libraries. 
  
EXPLANATION: 
Most programs are written and compiled and only contain code the author has 
written. Standard functions such as printf and strncpy are stored in runtime 
libraries. When the program is initiated, a runtime linker adds in these 
little bits of code. The main benefit is that lots of work is saved. An 
author doesn't need to re-write printf every program he writes. These 
libraries of pre-written functions are called shared object libraries. When 
a program is written to use these, that program is called a dynamically 
linked program. That is it will dynamically load functions as and when it 
need them. 
  
We can exploit this hole in ld.so by specifying our own library functions. 
In fact, this code replaces two standard C library functions, openlog and 
getpass. 
  
getpass is used when a program wants a password to be entered, without 
echoing to the display. openlog was added because some systems have a 
different way of initiating logins. 
  
The main crux is that both of these functions are executed when login (which 
is called when telnetd finds an incoming connection) is running as root. Any 
code which is executed then will be executed as root. My two trojan 
functions simply execute /bin/sh as uid 0. 
  
getpass is used in a normal /bin/login and is called after you enter your 
login name. Some systems that use shadow passwording will find (if you 
examine the source) that getpass isn't used. To circumvent this, we add 
openlog which, if a site is shadowed is probably going to be compiled in. 
This is the default with the shadow setups I've seen. 
  
METHOD: 
  
Method One (If you have an account on the machine you want root on. Try this 
            first.) 
  
(1) gunzip and untar the source into a directory, eg /home/squidge/lib_hack 
(2) compile the programs by typing make all 
(3) wait 
(4) you will have a file /tmp/.libroot.so 
(5) type telnet 
(6) at the telnet> prompt, type env def LD_PRELOAD /tmp/.libroot.so 
    This tells telnet to pass the environment variable LD_PRELOAD to the 
    target machine. LD_PRELOAD points to our trojan library. 
(7) type open localhost 
(8) If you don't get a prompt bash#, but get login: type something like test 
    You should now be greeted with bash#. Type id and see you are root. 
    Note that telnetd will time you out, so make some attempt at a backdoor. 
  
Method Two (If you have no account on the target machine) 
  
(1) as above 
(2) as above, if you are running the same hardware as the target. If you are 
    on different processors, try compiling on a different machine. If you 
    know what you are doing, try changing the target architecture used by 
    gcc and ld. it is the -m flag with ld. 
(3) assuming you have the correct binary, open an ftp connection to the 
    target 
(4) using bin mode, upload your trojan library to the targets incoming 
    directory. 
(5) switch back to your machine, start telnet and specify the path of the 
    targets ftp directory as your LD_PRELOAD. On linux this is normally 
    /home/ftp/incoming. On others generally /var/ftp/incoming or 
    /etc/ftp/incoming. 
(6) as number 8 above. 
  
If you opt for method 2, you will need a pretty good idea of what is going 

on. It is not for the fainthearted. If demand is high, I may release a new 
set of .o files for different architectures. There should be no need. I can 
compile for Sun(SPARC), M68 and x86 on my linux box. So can you. 
  
HOW TO PROTECT: 
There are a few ways. If you have a statically linked login, then you are 
safe. setuid programs ignore LD_PRELOAD so one you have logged in, you 
cannot subvert the system. 
  
You can patch telnetd to wipe all but a few env variables. There are many 
widely pieces of available code to demonstrate this. 
  
FINALLY: 
  
Thats all I can think of. If you have any questions, email 
                         [e-mail] 
                            (The Guild homesite) 
  
  
--