Obfuscated ELF Objects

I have blogged before on reverse engineering/binary analysis tools and how incredibly easy it is to break them. Prior works on the de-obfuscation of obfuscated binaries have concentrated on the accurate dead listing of executable code. These methods mostly concentrate on detecting 'junk bytes' or data within code sections. This is mainly done by determining what instructions are actually executed at runtime, without actually executing the object. I have researched ways to throw off these tools by manipulating the ELF object data that surrounds this code instead.

The search is limited to ELF object values that analysis tools use and that the OS linker, and loader does not, while maintaining runtime functionality. Unfortunately I have found _many_ ways to accomplish this. Most of the techniques disable or otherwise subvert the majority of analysis tools out there. Here's a few off the top of my head.

elf_header e_ident[EI_CLASS]
The Linux kernel doesn't check this value, make it whatever you want, your object will continue to function. Unfortunately most analysis tools will cease to work, only IDA pro will default to 32bits, unless you set it to ELFCLASS64, the demo version of IDA Pro will complain you can't disassemble 64 bit objects with that version. I sent a patch to the LKML for it.

elf_header e_phnum
Depending on the object you choose, you can increment this value a couple of times safely, and most of the time analysis tools that use the program header instead of the section header (IDA pro) will simply fill its analysis output with garbage from fake program header segments. Wont work on all objects, as you cant always choose the data that sits just beyond the legitimate program header entries. And some may cause the loader to throw your binary out upon execution.

section header sh_size
When the section header is present tools like IDA pro use it to perform analysis (yes you can force using the program header). Change the sh_size member of any section to any value you want, and the analysis will be incorrect.

Remember, when writing binary analysis tools you have to assume the object your parsing is malformed. How would the real OS loader treat it? That's what analysis tools must do, emulate the real environment, not the standard.

*I am in no way bashing IDA pro, it's far more powerful then anything else out there right now. But I had to use an example :] In fact to Ilfak's credit most other tools refuse to even read or fail completely (crash) when reading most objects I was manipulating.

Too Much Going On!

Ok RSA just ended and I'm back from CA. I never thought I would be happy to see Charlotte, but I am. There is a lot going on right now in security. Lots of unimportant stuff and important stuff at the same time. This post will attempt to capture my feelings on some of it.

RSA 2007 - Thank you NWA for making me 10 hours late, spilling water on me 25,000 feet in the air and for making my flying experience with your airline generally crappy. It was a good show though, see you there next year.

Public Hash Database - Excellent idea. I post a hash of a txt file saying what Ive potentially discovered, place it in public view and when my research is complete I post the txt file and my work. And if it didnt work out then no harm done.

Fuzzers and Co-operation In An Alpha Male Community - Co-operation? hah! Not going to happen. And I think fewer people are using public fuzzers then previously thought. New fuzzers come with an extremely limited expiration date. Once they stink up the refrigerator they are put aside while a new one is created to find new bugs in a new protocol. Rarely are huge bugs uncovered with them, and if they are, the author isnt sharing his fuzzer with the public.

Solaris Telnet Vulnerability - What the hell guys? In all seriousness there is WAY to much mailing list traffic over this bug. If your running telnet on the internet you deserve whatever happens. The End.

Vista UAC Design Issues - I almost feel bad for Microsoft, they have to balance usability with security and anyone working in security can tell you thats a tough job.

Also why is googlepages so slow these days?

Yah that about sums it up for now. My posts are real bad these days and I apologize for that. I promise it will get better.

Quiet reporting of loud vulnerabilities

Did you happen to catch the Solaris ICMP DOS vulnerability? If your like me you found out second hand from the ISC handlers diary. I have since found an entry on securityfocus about it and CERT. From the advisory Sun produced I think its safe to say when exploited, this vulnerability causes your box to go down, and go down hard. The stack trace sun provided gives some clue, but not much, and I don't have a Sun box to go poking around on to find out exactly how to trigger it.

Vulnerabilities like this are why I don't like classifying vulnerabilities by 'Remote DOS' alone. First of all there is a difference between a Remote DOS vulnerability where the attacker must first 'establish a TCP connection, authenticate and then bring down the box' and a 'spoofed ICMP packet =death of your box' vulnerability. The people at CERT correctly slapped 'unauthenticated attacker' to their advisory. Access to information is important, especially on critical systems. The fact a random anonymous person can deny you legitimate access to your information from anywhere is _bad_. While its not the same as that random person having access to that information it should still be considered a vulnerability of concern.