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:stauffacat_private]
Sent: Monday, September 10, 2001 11:26 AM
To: Oliver Petruzel
Cc: rstat_private; bugtraqat_private;
incidentsat_private; focus-virusat_private;
vulnwatchat_private; contributeat_private
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"?
----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Sep 10 2001 - 13:07:00 PDT