I'm not an expert in C or the ELF filestructure. Here is what I did:

1) Read the Recurse.pl file. It's essentially the command:
      find ${directory} -type f -chmod +x -exec ${cleaner} ${options}
\{\} \;

   $directory defaults to '/'
   $cleaner defaults to './kill'
   $options defaults to ''

      Nothing to see here, move along.

2) Read the Makefile. It compiles the executable (using a potentially
    compromized gcc, ld, etc.) and copies it (using a potentially
    compromized cp) so that there are two versions of the executable
    (./temp and ./kill). It runs ./temp on ./kill, ostensibly to
    clean it, then deletes ./temp

3) Read kill.c.

   When you ask it to analyze a file, kill appears to do only that-
   it reads but does not write. It reads the ELF header. If the
   ELF header doesn't exist or is not an executable header, it dies.
   If the ELF header exists and is executable, it reads the text
   segment and then the data segment. It accepts only the text segment
   with an offset from the beginning of the file of 0 (that is, the
   first text segment).

   It calculates the following:

   padding = datasegment's virtual address - ( textsegment's address +
                                               textsegment's size )
           = amount of information between beginning of data segment
             and end of text segment

   psize = ( end of textsegment ) - execution entry point
           = amount of information between end of textsegment
             and beginning of execution

   poffset = ( end of textsegment ) - psize
           = ( end of textsegment ) - (end of textsegment) + execution
             entry point
           = execution entry point

   If the padding is too large (there is too much space between the
   data segment and text segment) then the file is judged to be
   non-infected, and non-protected.

   If the padding is not too large, and the psize is 4096 then the
   trojan is declared active. If the psize is not 4096 then the
   trojan is declared inactive and the file protected.

   When you ask it to disinfect a file, it first analyzes the file
   and makes the calculations, above. Then it alters the ELF header,
   so that execution will begin with the actual program code, not
   the trojan code (assuming the trojan stores the offset of the
   program code at offset 1). It leaves the trojan in place, though
   inactive, presumably so that the file will not become reinfected
   with an active trojan. This step bothers me.

   When you ask it to make an innocent file immune, it does all of
   the above calculations, with one change:

   poffset = end of the first textsegment in the file

   Then it walks through the all of the program headers named in the
   ELF header. For each one except the textsegment itself, it pushes
   it forward in the file by 4096 bytes. Then it grows the textsegment
   by 4096 bytes. It updates the section header, and pushes the end
   of the file out by 4096 bytes. I have some trouble with how it
   does this.

4) Created an unpriveleged user account, put some executable files
   in a directory owned by this user, moved the sources of this
   stuff to that directory, and created a symlink from `./kill' to
   '/bin/touch'. Modified the Perl script to start with '.' instead
   of '/', and had it execute. This effectively executed /bin/touch
   on all of the files in the directory. The Perl script appeared
   to perform as advertised.

5) Copied fresh copies of an executable (GNU bash, in this case)
   to the directory. Ran strace and saved the output to a file.
   (the command was 'strace ./bash -c "touch bleh" 2> nonimmune').
   Immunized the executable with `./kill 3 <executable>', then
   ran strace again ('strace ./bash -C "touch bleh" 2> immune').
   Checked the differences between the two strace outputs. Aside
   from predictable differences (times and PIDs had changed,
   of course,) the executable behaved the same as observed by
   strace before and after immunization. The file before immunization
   differed from the file after immunization, however (diff
   reports 'Binary files original and immunized differ').

From what I can tell, this program does more or less what it claims
it does- that is, it ensures that the space between the text segment
and the data segment in an executable is too small for an infection
by something that infects in his space.

I have a few problems with it, however.

First, in the event that something is already present, which it
assumes is the trojan, in the file, it does not delete the trojan.
This seems odd. One explanation is that the virus code occupies
space, keeping the file from being reinfected. If this were so,
it would be better (seems to me) to overwrite the code with 'X's,
or some other nonfunctional component. Another explanation is
that the so-called virus code is not virus code at all, but, rather,
functional code which is necessary for the functioning of the
program, and a modification made to this code would change the
program's functionality.

Second, when updating a file it acts on the original. If there
is a problem while it is writing, the original will be useless.
This seems like a dangerous property to have, when globally updating
system binaries.

I am most troubled, however, by the actual program logic. What
it claims to do is decrease the slack space between the data segment
and the first text segment. I don't know much about the ELF format,
but it feels a lot like nonsense to me that this slack space would
exist in the first place. Moreover, the actual functionality of
the program is to increase the size of the first text segment by
4096 bytes, _and move everything else forward by 4096 bytes_.
Unless I am misunderstanding something, this does nothing more than
increase the size of the first text segment.

Details have not yet been published about the functioning of
this trojan, but I suspect that it actually infects the first
text segment of the file. That the case, this change does nothing
except guarantee that the text segment will be big enough to
accommodate 4096 extra bytes without changing the filesize.

I'd recommend against using this software.

  -- Matt

-----Original Message-----
From: John Stauffacher [mailto:stauffacchapman.edu]
Sent: Monday, September 10, 2001 11:26 AM
To: Oliver Petruzel
Cc: rstcoders.com; bugtraqsecurityfocus.com;
incidentssecurityfocus.com; focus-virussecurityfocus.com;
vulnwatchvulnwatch.org; contributelinuxsecurity.org
Subject: RE: Remote Shell Trojan: Threat, Origin and the Solution

It sounds to me like this is a feeble attempt to spread this "trojan"
even more. I dont like the sound of it. Anyone out there willing to
"cleanroom" this "immunizor"?

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]