[Gllug] Memory scanning

[Nix]

On 5 Sep 2010, James Courtier-Dutton said:

> On 5 September 2010 00:08, Steve Parker <steve at steve-parker.org> wrote:
>> On 04/09/10 11:44, James Courtier-Dutton wrote:
>>> I am looking for a tool that does the following.
>>> 1) Scan an executable binary file to create a checksum.
>>> 2) Runs the executable program as a process.
>>> 3) Halts execution of a single process
>>> 4) Scans the entire process address space to create a checksum
>>> 5) Compares the two checksums to discover if any virus or malicious
>>> code has been inserted.
>>> 6) If all is well, allow the process to schedule again.
>>>
>>
>> Sounds rather like Text Relocation - SELinux will do that for you -
>> http://web.archive.org/web/20080514003359/http://people.redhat.com/drepper/textrelocs.html
>> (the original seems to have disappeared, and Drepper's redhat page
>> directs you to his personal page, suggesting that he left, I must be out
>> of touch!)
>
> I agree that my scan idea will have to allow for relocations, but I
> believe all the data I need for that is in the elf file format.
> So, so long as I can determine which executable was supposed to be
> loaded, I can use the info in the elf file to handle the relocations
> in a special way.

Well, yes, and text relocations are much rarer than they used to be,
because the x86-64 ABI does not support them.

However, you'll *also* need to verify the *non-text* relocations,
particularly the PLT but also the GOT as well because an attacker could
just as well modify one of those, and the next time you call printf() or
whatever, whoom. Of course these are not in .text...

> Hopefully, I could detect if the relocations are the same as I would
> expect them to be, or in some way modified.

Sure! You'll need to (in effect) reimplement most of ld.so in reverse,
since relocation is its only significant job. Note that the relocations
in question disappear once they are applied by ld.so; for text
relocations, the appropriate bit of the binary text is overwritten, and
for PLT relocations you'd have to cater for their being lazily relocated
(and thus lazily overwritten with a direct call to the function) the
first time each function is called. (You could dictate that everyone
runs with LD_BIND_NOW=1 to ameliorate this, but this has performance
implications and doesn't make your horrible job much simpler.)

> For example, in the elf, I might have a location in the code that
> calls a library function. So, when scanning memory, I could identify
> the location in memory where it makes the function call to the lib,

(that's what the relocations point to)

> and verify that it is still pointing to the correct lib function.

How do you know where it was supposed to be pointing? You'll need to do
the same resolution jobs as the dynamic linker in order to figure that
out. Note the presence of numerous insane ELF features like DT_FILTER
and symbol interposition which make it really fun to figure out where
the hell something is meant to be pointing. Oh, and the symbols can be
kilobytes long (e.g. in C++ programs, which often have a *lot* of
symbols): there is a hash table in some binaries to speed the comparison
of those symbols up, but not in all.

And don't forget prelinking, which changes the rules again (a bit), and
which may or may not apply even if a particular binary is prelinked
(as the feature turns itself off if any dependent library has changed).

ld.so does all of this for you. Now you have to do it again, and compare
the results, without having the rootkit spot this and fool you. Good
luck: it seems impossible to do robustly to me (maybe you could have a
daemon in a different privilege domain do the work, so the rootkit
couldn't interfere with it?)

> This would catch root kits that use hooks to hide themselves.

This isn't Windows. Have there actually been any rootkits that use PLT
manipulation of running binaries to hide themselves? It seems like a
fiercely complicated way to do things, given that in order to do this
you already must have sufficient privileges to execute arbitrary
nonprivileged code, and it would seem easier to try to spread to more
machines than to hide yourself on this one.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug