loading of shared objects and executables

[Ángel González]

On 27/10/12 01:28, Michael Zintakis wrote:
> Hi Roman,
>
>
> Bolshakov, Roman wrote:
>> I also studied that in the spring. You can find a lot of details on
>> the page: http://www.acsu.buffalo.edu/~charngda/elf.html
>>   
> Very good reference this, thank you - I'll look into it in more detail
> over the weekend! OK, in a nutshell, what I am after is, basically,
> two things:
>
> 1. Find the portion of the kernel code, which is responsible for the
> initial loading the file for execution (i.e. when I type "iptables"
> from the command line for example). This will help me to modify that
> code so that the file which is about to be loaded is "verified" first
> and raise a security exception if something is wrong with it.
> 2. Once I've done that, if there is a possibility to identify all .so
> (shared objects) on which this executable depends (by looking at its
> headers for example), I could do the same as step 1 above for all
> dependent .so files. If not, then I'll have to pass control to ld.so
> and intercept the point prior to where these .so are about to be
> loaded, so that I could do the verification - as in step one above,
> but for the shared objects. If everything checks out, then I'll pass
> control over to ld.so.
>
> I am guessing the picture when statically compiled executables are run
> is more or less the same with the exception of loading Ñ‚Ñ
е shared
> libraries, as they are included as part of the file which needs to be
> executed - am I correct in thinking that?
>
>> Dynamic linker is loaded by kernel after the kernel reads ELF headers.
> And it is precisely at that point I need to take control to "verify"
> the executable and, if possible, all .so files on which this file
> depends.
>
>>  Then it passes control to the entry point of the linker. If you use
>> glibc the entry point is named _dl_start. So, in general, you need to
>> make breakpoint on _dl_start.
>>   
> I guess I would need to do that only if I could not find the .so files
> on which this executable depends, otherwise the verification could be
> done much earlier and I could then let ld.so do its job, right?
>
Don't forget about dlopen()
The appropiate place would generally be on the dynamic linker, except
for static binaries.

I would probably try to hook the mmap() calls with PROT_EXEC and block
them if it isn't a verified file.

A verified binary could bypass it by loading another program in a
different way, but as I guess you wouldn't "verify" such binary, that's
probably ok, since normal users will use mmap(). The problem of
verifying binaries (scripts) in dynamic languages, is worse anyway.