Attack using a shared library, how?

Attack using a shared library, how?

Post by Saj » Tue, 21 May 1996 04:00:00



My Linux box was broken into using a file that was sent to me. The file
is 3295 bytes in size and is an:
ELF 32-bit LSB dynamic lib i386 (386 and up) Version 1 file
I was told that anon ftp might be the starting point for that attack.
The attacker issued the following commands (or similar) after he gained
root access:

cp /bin/sh /tmp
chmod 4755 /tmp/sh
/tmp/sh

Can anyone provide me with detailed information.
Thank you.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzFnhVwAAAEEALhjqy6lf2vZVwxEzPWXoN3Zwb6A2dQnbBF2d1uzKcdaNbwk
SSWN6ZbtNATHWgrj1n2Mze27CUDGusTJb/ghvy8pluXEo5aDg4w+/lhP5YJHQXdb
mUbCIX9jdEnoMjLuTWI9zKO+EhfeDNrRjrJImBNdbqx4/a7RdI+/+YTa/qAxAAUT
tCBTYWdpIERhciBBbGkgPGF1MjczQHRvcmZyZWUubmV0Pg==
=6QdH
-----END PGP PUBLIC KEY BLOCK-----

 
 
 

Attack using a shared library, how?

Post by Jacob Langse » Tue, 21 May 1996 04:00:00


-----BEGIN PGP SIGNED MESSAGE-----

Quote:>My Linux box was broken into using a file that was sent to me. The file
>is 3295 bytes in size and is an:
>ELF 32-bit LSB dynamic lib i386 (386 and up) Version 1 file
>I was told that anon ftp might be the starting point for that attack.

The individual uploaded a hacked libc into your ftp/incoming directory.
He then exported the LD_PRELOAD path via telnet negotions.  After Inetd
invoked /bin/login, (Inetd)UID=(/bin/login)EUID so the alternate library
was honored.  They probably modified the call to crypt() during login to
allow automatic success.

As a fix, you could apply a wrapper around /bin/login to cleanse all
instances of unwanted environment variables before execing it.  I'll
include such a wrapper (must be compiled statically):

/* This is a login wrapper that removes all instances of various
   variables from the environment.

   Original author:      Lawrence R. Rogers

   This is a modified version and is only partially based on the work
   of the original author; Lawrence R. Rogers is not responsible for
   this version.

   NOTE: THIS PROGRAM MUST BE COMPILED STATICALLY TO BE EFFECTIVE
   AGAINST EXPLOITATION.  For example:

   gcc -static -o login FILENAME

   Where FILENAME is the name of the file to which you saved this.

   To install this wrapper, first move `/bin/login' or
   `/usr/bin/login' (make sure it is the one that telnetd (8)
   executes) to `/bin/login.real' or whatever you defined
   _PATH_LOGIN_REAL to be.  Then replace the original with the
   executable generated by compiling this file (again, make sure that
   this executable is statically linked or it will be ineffective).  */

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <syslog.h>

#ifndef SYSLOG_FACILITY
#define SYSLOG_FACILITY   LOG_AUTHPRIV
#endif /* SYSLOG_FACILITY */

#ifndef SYSLOG_LEVEL
#define SYSLOG_LEVEL   LOG_ALERT
#endif /* SYSLOG_LEVEL */

#ifndef _PATH_LOGIN_REAL
#define _PATH_LOGIN_REAL   "/bin/login.real"
#endif /* _PATH_LOGIN_REAL */

/* This should be a list of environment strings that we want to allow
   users to pass to login (1) (and possibly to the shell).  These will
   be matched using strncmp (3).

   This list should really only contain the names of environment
   variables that control display parameters, as any others should be
   able to wait until the shell's rc files (e.g., `.login',
   `.profile', `/etc/profile', etc.,) are executed.  */
static const char *legal_env_strings[] =
{
  "DISPLAY=",
  "TERM=",
  0

Quote:};

int
main (argc, argv, envp)
     int argc;
     char **argv, **envp;
{
  char **p1, **p2;
  int i;

  openlog (argv[0], LOG_PID, SYSLOG_FACILITY);

  for (p1 = p2 = envp; *p1; p1++)
    {
      int found = 0;

      /* Traverse the list of legal environment strings.  If we have a
         match, pass it in envp; otherwise, send a warning to the
         system logger.  */
      for (i = 0; legal_env_strings[i] && !found; i++)
        {
          if (!strncmp (*p1, legal_env_strings[i], strlen (legal_env_strings[i])))
            found = 1;
        }

      if (found)
        {
          *p2++ = *p1;
        }
      else
        {
          syslog (SYSLOG_LEVEL,
                  "illegal environment string: `%s'\n", *p1);
        }
    }
  *p2 = 0;

  closelog ();

  execve (_PATH_LOGIN_REAL, argv, envp);
  perror (_PATH_LOGIN_REAL);

  exit (1);

Quote:}

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMaA3S7t34LFBwvDtAQFEegQAqDxHsyYzaLsK02NQmwlvF/fO5LH6nMY0
RyLKRvpToIfTxF0JUqk1tMNb7eP8lunx031cDoG+n+tb+CKJiNU39nvt+4YPIe/h
1FaqlBnfFJGF+1Q3CPvzeYSmA2QfOKksfv/BSMjIWW5B8136wuTCHIGp3Hw4bvno
hkkTYLLZhKM=
=EdMS
-----END PGP SIGNATURE-----
--
      /          "Meddle not in the affairs of dragons, for             \
 *}=={*}>======-  thou art crunchy and go well with ketchup."  -======<{*}=={*

    Musashi          - - -=- Finger for PGP key -=- - -             Musashi

 
 
 

Attack using a shared library, how?

Post by Squid » Tue, 21 May 1996 04:00:00


I would just like to state that Saj did this, not me :-
: My Linux box was broken into using a file that was sent to me. The file
: is 3295 bytes in size and is an:
: ELF 32-bit LSB dynamic lib i386 (386 and up) Version 1 file

Gday. Sounds like libroot. nm the file and look for openlog and getpass.

What happens is that telnetd can be persuaded to load other files before
executing /bin/login. If /bin/login is dynamically linked (fetches code
at runtime) then you can replace one of the functions with a new one.

This *ed function generally execs a shell as root. To fix this,
apply one of the freely available patch's to telnetd or grab a pure one
from sunsite.

There was a readme with libroot-0.9a that explained how to fix telnetd.

: I was told that anon ftp might be the starting point for that attack.
: The attacker issued the following commands (or similar) after he gained
: root access:

They would probably have pushed it into /home/ftp/incoming and then just
used env def LD_PRELOAD /home/ftp/incoming/libroot.so.

Once in, you have about 60 seconds before login times out, so you copy a
shell, and/or add a new user to the passwd file, with uid 0. Check
/etc/passwd.

Squidge

--
                                "don't mess"
                             squidge - The Guild

 
 
 

Attack using a shared library, how?

Post by Mike Sch » Tue, 21 May 1996 04:00:00


[re: telnetd shared library vulnerability]
: As a fix, you could apply a wrapper around /bin/login to cleanse all
: instances of unwanted environment variables before execing it.  I'll
: include such a wrapper (must be compiled statically):

Since this was a Linux box, and source is available, why not just compile
login static?

That wrapper, however, becomes an interesting idea for systems where
source is unavailable to the average admin; I'll have to give it a good
looking over.  Thanks for posting it.  A thought which parallels the
metacharacter parsing debate occurs to me, however:  why not limit
environment variables to a list of known reasonable ones, rather than
merely t* 'bad' ones?

The person should also, while at it, upgrade to a newer release of the
telnet daemon that passes fewer variables on.

      -Mike

--
Michael Brian Scher   (MS683)   | Anthropologist, Attorney, Part-Time Guru


   I'm a legal anthropologist; what's an illegal anthropologist?

 
 
 

Attack using a shared library, how?

Post by Jacob Langse » Tue, 21 May 1996 04:00:00



>metacharacter parsing debate occurs to me, however:  why not limit
>environment variables to a list of known reasonable ones, rather than
>merely t* 'bad' ones?

[... wrap.c: ...]
/* This should be a list of environment strings that we want to allow
   users to pass to login (1) (and possibly to the shell).  These will
   be matched using strncmp (3).

   This list should really only contain the names of environment
   variables that control display parameters, as any others should be
   able to wait until the shell's rc files (e.g., `.login',
   `.profile', `/etc/profile', etc.,) are executed.  */
static const char *legal_env_strings[] =
{
  "DISPLAY=",
  "TERM=",
  0

Quote:};

[... wrap.c ...]

-jwl
--
      /          "Meddle not in the affairs of dragons, for             \
 *}=={*}>======-  thou art crunchy and go well with ketchup."  -======<{*}=={*

    Musashi          - - -=- Finger for PGP key -=- - -             Musashi

 
 
 

Attack using a shared library, how?

Post by Saj » Tue, 21 May 1996 04:00:00



> I would just like to state that Saj did this, not me :-
> : My Linux box was broken into using a file that was sent to me. The file
> : is 3295 bytes in size and is an:
> : ELF 32-bit LSB dynamic lib i386 (386 and up) Version 1 file

> Gday. Sounds like libroot. nm the file and look for openlog and getpass.

I did that, and it did show both 'openlog' and 'getpass':
00000300 t gcc2_compiled.
000002d0 T getpass
00000360 t init_dummy
00000300 T openlog
         U system

Quote:> : I was told that anon ftp might be the starting point for that attack.
> : The attacker issued the following commands (or similar) after he gained
> : root access:

> They would probably have pushed it into /home/ftp/incoming and then just
> used env def LD_PRELOAD /home/ftp/incoming/libroot.so.

Hmmm. that explains the connection to my wu.ftpd in the logs.

Quote:> Once in, you have about 60 seconds before login times out, so you copy a
> shell, and/or add a new user to the passwd file, with uid 0. Check
> /etc/passwd.

This explains why there were several connections to in.telnetd in the logs. But what the attacker
did was he sent a file through DCC on IRC to me and I accepted it 'cause I thought there was no
harm in doing that as long as I don't execute the program. He wasn't able to upload it using ftp
because the permissions do not allow him to do so.
 
 
 

Attack using a shared library, how?

Post by Mike Sch » Wed, 22 May 1996 04:00:00


: [... wrap.c: ...]
: /* This should be a list of environment strings that we want to allow
:    users to pass to login (1) (and possibly to the shell).  These will
:    be matched using strncmp (3).
 [...]

Ah. I stand corrected having not yet read the code.

Remember:
1. Read code
1.5 Make sure you read it....
2. Comment
3. Kick self for missing something

      -Mike
--
Michael Brian Scher   (MS683)   | Anthropologist, Attorney, Part-Time Guru


   I'm a legal anthropologist; what's an illegal anthropologist?

 
 
 

Attack using a shared library, how?

Post by Scott » Wed, 22 May 1996 04:00:00



> -----BEGIN PGP SIGNED MESSAGE-----

> >My Linux box was broken into using a file that was sent to me. The file
> >is 3295 bytes in size and is an:
> >ELF 32-bit LSB dynamic lib i386 (386 and up) Version 1 file
> >I was told that anon ftp might be the starting point for that attack.

> The individual uploaded a hacked libc into your ftp/incoming directory.
> He then exported the LD_PRELOAD path via telnet negotions.  After Inetd
> invoked /bin/login, (Inetd)UID=(/bin/login)EUID so the alternate library
> was honored.  They probably modified the call to crypt() during login to
> allow automatic success.

I was curious as to what the conditions for this attack will work..
Someone tried the same idea on my machine, but I pretty much figured it
didn't work because the perms on files put in ~ftp/incoming were set at
0600 with root.daemon ownership.. Any chance this attack could have
worked? (I doubt it, considering the lack of any activity aside from the
ftp put and then a telnet connect.. Nothing else from that site.. And I
would guess that if it had worked, I shouldn't have even found that much
in the logs...)

--
---------------------------------------------
-- Ok.. It's cheezy.. I know it.. Don't    --
-- tell me...                              --
---------------------------------------------

-- And DON'T call it GayNet! :)            --
---------------------------------------------

 
 
 

Attack using a shared library, how?

Post by Squid » Wed, 22 May 1996 04:00:00


I would just like to state that Scotty did this, not me :-
[libroot attack snipped]
: I was curious as to what the conditions for this attack will work..
: Someone tried the same idea on my machine, but I pretty much figured it
: didn't work because the perms on files put in ~ftp/incoming were set at
: 0600 with root.daemon ownership.. Any chance this attack could have

Gday. The general attack goes: upload the file to a known location,
connect to that site with LD_PRELOAD pointing to the library, and then
get 60-90 secs of root access.

Seeing as in.telnetd runs as root, it pays no respect to file
permissions. Therefore, it doesn't matter that libroot.so is owner
readable only.

: worked? (I doubt it, considering the lack of any activity aside from the
: ftp put and then a telnet connect.. Nothing else from that site.. And I
: would guess that if it had worked, I shouldn't have even found that much
: in the logs...)

It could be that your in.telnetd or /bin/login is patched. Or statically
compiled. The hallmarks of an attack are a few telnetd connections that
don't have login attempts, coupled with an ftp put.

A hacker would generally add an entry to /etc/passwd, or unlock one of
the system accounts. Check for these.

Squidge

--
                                "don't mess"
                             squidge - The Guild

 
 
 

Attack using a shared library, how?

Post by Scott » Wed, 22 May 1996 04:00:00


I guess what I'm getting at is, is there a way to prevent this sort of
attack w/o a login wrapper? Or does it always work if you allow puts to
~ftp/incoming, and aren't running a login wrapper...?

--
---------------------------------------------
-- Ok.. It's cheezy.. I know it.. Don't    --
-- tell me...                              --
---------------------------------------------

-- And DON'T call it GayNet! :)            --
---------------------------------------------

 
 
 

Attack using a shared library, how?

Post by Squid » Wed, 22 May 1996 04:00:00


I would just like to state that Scotty did this, not me :-
: I guess what I'm getting at is, is there a way to prevent this sort of
: attack w/o a login wrapper? Or does it always work if you allow puts to
: ~ftp/incoming, and aren't running a login wrapper...?

Gday. libroot can be used (bad login/telnetd permitting) as long as it is
on the system. As long as the hacker knows where it is, they can use it.

This could be via IRC/dcc, ftp, user having an account and any other
method of putting a file on your host.

In short, the only way to protect is to patch /bin/login and/or in.telnetd.

Sq

--
                                "don't mess"
                             squidge - The Guild

 
 
 

Attack using a shared library, how?

Post by Rout » Thu, 23 May 1996 04:00:00



: |I guess what I'm getting at is, is there a way to prevent this sort of
: |attack w/o a login wrapper? Or does it always work if you allow puts to
: |~ftp/incoming, and aren't running a login wrapper...?

        Patch yur telnetd.  The shared lib exploit was a big thing sevral
        months back when it was first widely discovered.  Patches were made
        available almost immediately.  Of course, the prefered method of
        fixing this hole is both the updated telentd AND a login wrapper.
        I can't tell you how many times ppl have ftp'd the exploit from my
        site, then *tried* the exploit on my site.  The world is peppered
        with morons.
--

        ...I am the only way to go.  I am the way of the future...

 
 
 

1. Using static libraries and shared libraries in same program?

I have a program I have been working on that uses a static library.
I recently upgraded to Slackware linux 3.0, ELF.  Now when I try
to compile my program, the linker gives me nasty massages about

"undefined reference to `ALL_THE_FUNCTIONS_IN_THE_LIBRARY_I_USE'"

The very same library worked before I upgraded.  The linker finds the library,
because if I change the -L/THE_RIGHT_DIRECTORY to somewhere else, the linker
complains about not finding the library at all.  If I include the flag
"-static"  and reset all the directories to find the static versions of all
the other libraries, I still get the same error from the linker about this one
library!  It worked before... what am I doing wrong?  Maybe I don't understand
something that I should.  Any suggestions?  Do I need to get a version of the
library compiled using a newer version of Linux?

Erik B. Andersen

-------

-------

2. spooky partitions

3. Using libtool to build shared libraries that depend on static libraries

4. some easy questions......

5. Will strip(debug shared library) == nodebug shared library ?

6. Win95 network install, no floppy?

7. Help with building shared libraries with dependencies on other shared libraries

8. DCL to Unix Shell translator?

9. Question: Inclusion of shared libraries during linking of shared libraries

10. Shared library loading shared library.

11. Need a Shared Library Guru: beyond simple shared library question

12. When is a shared library not a shared library?

13. Socket connections using shared libraries