Re: [PLUG] ELF Init section

[Tim Peeler <tim@iss.dccc.edu>]

On Fri, Jun 01, 2001 at 03:01:16PM -0400, Greg Lopp wrote:
> On Fri, Jun 01, 2001 at 02:11:37PM -0400, Tim Peeler wrote:
> >    If one were to use the init section of an elf header to execute
> >    arbritrary code (for example someone created a worm/virus that
> >    planted arbitrary code into the init section), would the init
> >    section be executed with the permissions of the user executing the
> >    code or would it be executed with the permissions of the loader?
> 
> By no means an authoritative answer :
> 
> Logic would dictate that the init section is executed with euid
> permissions.  If it were the other, there would really be no
> security as gaining the loader's permission level would be
> trivial.  You wouldn't need a worm/virus to plant arbitrary code
> in the init section of an elf executable, you could do it
> yourself to your own hello_world.c program.  
> 
> But who would this loader be anyway?  Wouldn't the loader just be
> your shell process makeing an exec() system call?
As part of executing the binary, it has to pass through the loader
(ld.so) and it gets mangled and manipulated in ways that boggle my
mind.  The main thing the loader does is (as I understand it) is
to load the program into memory, combine it with sections of libs
as required so that the libs that it's dynamically linked with can
do their jobs properly.  As I understand it, the executable doesn't
call upon the libs to do their work, the loader does.  It's this
loader that binds everything together and makes it work.  From the
ELF Portable Formats Specification, Version 1.1 Tool Interface Standards,
Section 2. Program Loading and Dynamic Linking:

   Executable and shared object files statically represent programs.
   To execute such programs, the system uses the files to create dynamic
   program representations, or process images.  A process image has 
   segments that hold its text, data, stack and so on.  The major
   sections in this part discuss the following.

   * Program header <snip>...</snip
   * Program loading.  Given an object file, the system must load it
     into memory for the program to run
   * Dynamic linking. After the system loads the program, it must
     complete the process image by resolving symbolic references
     among the object files that compose the process.

The important part I'm looking at is the dynamic linking.  Earlier in
the text of this document it mentioned the binary loader (ld.so).  The
text mentioned (it's getting hazy, although I have the document here
I'm not going to go back through to try to find it) that the loader
is the actual program that binds (my words) the binary and the libaries
into the "process image" (the author's words).  

   Really the thing I'm concerned with, is that if the init section of
a binary is executed first, would that section be executed as the uid/euid
of the user who invoked the program or would that section be executed as
the uid/euid assigned to the loader (which is root).  The problem that
I see here, and the concern I have is that if the init section of a binary
is executed as euid of the loader, the any elf system will be open to
an init virus that can infect and spread itself through the use of the
init section of the binaries header.  This is all assuming a malicious
coder decided to use the init section were it vulnerable to this type of
exploit in the first place.

Something else that just keeps gnawing at my brain, is what binary format
do the various bsds use?  Surely they would use elf right?  In which case
they would be as vulnerable to the same type of thing as linux (still
assuming that the init section is executed as root not user).  Furthur
contemplation on the subject makes me less worried that the init section
is executed as root as the authors of the ELF format and the creators
of the loader should have surely seen this as an easy attack and have
taken appropriate precautions.

Perhaps this would be best to ask of the loaders maintaners.

Tim


______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug