Hallo people, first a quick intro about this article. This is going to be all about hardening againstmemory corruption attacks. You may commonly know these as 0days, stack overflows, heap corruptions, format strings, ect. Sure code fixing is the main defense but its reactive defense. It only works after the fact. That fact may be very well that you got 0wned. Aint that the sh*t? Originally I meant this to be about hardening the core OS but after I thought about it, it left out a few compiler based defenses I felt are important. The truth is that if a single a oh-day ruins your day than you FAILED. You have NOT done your job. Thats because nothing but the most top-notch exploit can bypass the modern day mitigations on a linux box, and even then it is highly situational. Also remember that most "hackers" these days are all teeth and no shell. If you got a better shell then you are already ahead. Who knows, maybe you'll learn a thing or two about what it takes to make a real modern exploit.
*disclaimer* this is not about local kernel 0day protection. My opinion is if youve let them get that far, well f*ck you, you havnt done your job.
//paxtest + checksec.sh
Paxtest and checksec.sh should be your first go-to tools when it comes to evaluating how exploitable* a system is. If you've ever been serious about targeting a box the 'old school way' you know that you try to mirror the target as much as possible. Same kernel, distro, services, ect to play with instead of doing the equivilent of screaming at their network and hoping no one hears you. Thats when you bust out paxtest and checksec.sh, and they are also the first tools you should be using to judge exactly what you need to fix on your box.
Paxtest can be found with a quick google and on my Ubuntu box at least it comes via a nice aptitude install paxtest :P Checksec.sh last I've seen can be found at http://www.trapkit.de/tools/checksec.html
First a quick use of paxtest. Paxtest creates and runs several test runs to check what kernel support for memory protections are in place. Run it with sudo paxtest blackhat ((the other option is --kiddie and they return the same result but I suppose back in the day kiddie made 'safer' checks that werent as accurate)) My 'out of the box' Ubuntu returns this for instance:
Code
As you can see the kernel protections are pretty sh*t :D But wait, Its got NX(linux's dep) and aslr!!! But holy sh*t look at all that other stuff that's vulnerable that can be used to aid in exploitation! And the aslr is crappy as hell! :P I bet a vast majority of you are having an exlamation mark above the head going on. Don't worry, it's STILL better then a CentOS or Debian box...
Next is checksec.sh This checks for binary protections of a given file, or optionally some running processes(all if root). Its a very nice complement to paxtest in judging the exploitability of a program assuming that there is a flaw. It can also check kernel defenses with --kernel(but that and fixing it will be an exercise for the reader). Typically you should run it with sudo checksec.sh --proc-all > checksec.log and sit back, it may or may not have a lot of output depending on how many processes you got going on, so it's best to save it somewhere. Again, heres my output for a 'out of the box' Ubuntu:
Code
Ill explain the different columns as we face them. A quick visual scan and a bit of intuition tell us the the google talk plugin would be pretty easy to exploit if we found a flaw in it. Well, assuming it would even be worthwile to investigate as a target in the first place :) another place, another place. Now on to the fun stuff!
//NX
First of all, if your cpu doesnt support hardware NX ((top of checksec.sh output)) Chuck it out and get one that does? There, fixed :)
//grsecurity
As you may remember from paxtest that my aslr only involves a handful of bits that is really pathetic against a real exploit(if it even bothers beating aslr head on :) ), and my heap protection and a bunch of other stuff is pretty shitty. This is where grsecurity comes in. You can get a full list of features at http://grsecurity.net/features.php that can do better justice explaining why it is important better than I ever could. It pretty much fixes almost everything. Why it's patches aren't part of the linux dev tree already is beyond me. You can get it from the same site's download section or if you are using aptitude you can get the package at http://kernelsec.cr0.org/
*disclaimer* read the F*cking page before you complain about stuff not working. Also this DOES install a new kernel. If need be, hunt down how to apply the patch to your own kernel source if you have a custom compiled one or it suddenly breaks on you.
Follow the simple instructions at the bottom of the page(if you can't, get a new f*cking hobby :D ). Its recommend you install paxctl while you are at it in case you ever need to change the configuration(why thats in the repos by default and not grsecurity that it controls is another mystery in life).
The only issue is that sometimes it conflicts with some firmware deal and will abort the isntall(did with mine). This means youll have to go the old school way of compiling it from the source. Check out grsecurity's wiki about that. I dont feel like writing an entire book.
//Canaries
Typically this is a protection you SHOULDNT have to worry about. But....looking back at checksec.sh We do a few times out of the box. Stack canaries are a specific set of bytes placed at the end of a stack buffer. The kernel keeps checking for this value whenever a program is running. Since the canary is before eip, you gotta trample the canary to get to eip during an exploit. The kernel is not too found of this idea and will slay the process quicker than you can say shell. Yeah, dont even get to 'shellc'(ode). There are some bypasses but frankly it out of anything makes stack overflows practically obsolete. If you find a process DOESN'T have it, you have to sigh and get it enabled youreself. That means recompiling :/ do a ./configure and then grep the makefile for a -fno-stack-protector and get rid of that retarded line(my lil bro is autistic and I tend to find that workd offensive, that shows how maddening it is to see 'production code' that uses that option. Assuming gcc is up to date, all shall be well. If the proggy breaks thanks to your changes...find an alternative >.>
//Relro
Ahh now to the stuff that seems like only exploit writers(or those serious
about learning it, and I mean serious) seem to be aware of. Relro comes in two fassions, partial and full. As you may have guessed full is better than partial. Partial relro is implemented with the gcc compiler options -Wl,z,relro what this does is reorganize a few internel elf data sections to make it more difficult to mess with(not really). And the non-PLT GOT sections is read-only. That last bit is pretty meaningless since it is barely used in exploitation anyways. Nowadays overwriting GOT in general is cool. Full one ups partial by making the ENTIRE got section read-only. With old-school protections that means practically all of your modern 0days are poof! Out the window and out of site :P In fact im still trying to dig up papers about crushing full relro but it's been no-dice so far. Too new and badass I suppose and likely any 'generic' technique would be relatively unknown and a quick ticket to fame or infamy. Anyways you get it running with gcc -Wl,-z,relro,-z,now And yeah, this likely means a LOT of re-compiling if youre paranoid.
//PIE
Ahh the older sister of relro. PIE'd executables are likewise badass. PIE stands for position-independent-executable. Heres the part that makes exploitation scary when youre back up looking at checksec.sh. See how all but the most vital daemons ARENT PIE? Not so good. So whats the big secret about PIE? To qoute wikipedia:
"PIE binaries are used in some security-focused Linux distributions to allow PaX or Exec Shield to use address space layout randomization to prevent attackers from knowing where existing executable code is during a security attack using exploits that rely on knowing the offset of the executable code in the binary, such as return-to-libc attacks."
Yep, this is your fancy, modern aslr. Ya know, the one that is even marginally effective? Technicalities and 'test-programs' aside, you can consider aslr to be good as disabled on any non-PIE program. Back to recomp time with a snazy -fPIE slapped onto gcc ;) doesnt work with --static Ive heard and prob shouldn't be used while compiling .so libs(but the final executable...definately). So far guess what the only real public bypass of PIE is? got overwriting. Remember what full relro was SOOOO good at? ;DDD Back up at checksec.sh, ever wondered why firefox 0days for linux are never bothered with? Ill let you draw youre own (obvious) conclusions.
(speaking of...)
//Conclusion
Ok, maybe this wasn't a 1-2-3 guide like some of ya may have hoped, but I hope those of you who have read it and havnt looked into modern exploitation have learned a thing or two about defending from 0days, and perhaps a catalog of what you gotta crush in the modern world to write those very same 0days.
References: Too many to count, google a good keyword and I've probably read the results and commited its contribution to memory ;P props to all the underrated exploit writers who don't get the credit they deserve and the guys like the PaX team that have the balls to say, "F*ck your zero days! Bring it!"
Note: If anyone has any information on screwing over RELRO or exploiting PIE, I'd love if ya sent me links/article names/blogs/etc that may be of interest ;)
No comments:
Post a Comment