tntcoda wrote:Being more specific, most modern operating systems ship with some kind of ASLR, which from what ive seen isnt at all easy to bypass. I would be interested if theres any papers on how it can actually be defeated? Plus theres things avaliable on top of this like stack protection, grsecurity and selinux locking things down further.

Jack,

I would really view it right the opposite. If you can find an OS fresh out of the box, you are most likely going to be able to exploit it. The reason being is it most likely has tons of patches that has yet to be applied. This even applies to OS's that have been in production for awhile.

Corporations get caught with their pants down when lazy Admin don't keep up with patches on their servers and workstations. New exploits are constantly being found. That is why hackers are constantly scanning systems. They are looking for version numbers and patch numbers so they can see if it might have a vulnerability that hasn't been patched yet.

tntcoda wrote:So am I correct in this line of thought? I suppose crashing a program can be considered just as serious, but being able to executing arbitrary code from an OS level vulneratbility or a running process seems to be fading away? Any other attack vectors relevant to these kind of vulnerabilities?

Jack, Windows 2003 Server is still one of the easiest OS's to get a reverse shell on, even though its been out for how many years? Here is a real world example:

I did a scan on my employers servers not long after being hired in IT. I noticed they were running service pack 1 when service pack 2 had been out for quite awhile. So here I go, I hit Google and find all the exploits I can find for SP1. I get the list and take it to the network administrator and say, "I can do this, this and this and take control of that server right now. Don't you think you need to get this patched?"

That is how easy it is to exploit a OS fresh out of the box or not.

Last edited by $w33p3R on Sun Sep 28, 2008 9:15 am, edited 1 time in total.

All of these features are basically raising the security bar on security. With each thing, the amount of skill and effort it takes to get a working exploit rises. That's the basic point of all the security stuff we throw out there. Whether it's firewalls or service hardening or whatever, if there is a person motivated enough and skilled enough with a lot of free time on his/her hands, eventually they will either figure out how to get in or give up to find something more fun.

In my opinion, we as security people can keep putting up barriers, but when we look at software development, even the folks that the developers frequently look up to such as Microsoft, are opting out of their own security measures (see the first article referenced). If we are running OS's with only the base services enabled and fully patched, I think that the bar is pretty high up there, but as soon as you start installing software on there, the attack vector just gets bigger. With Vista as an example, I am pretty confident that many people that got bothered by UAC just turned that puppy off and there goes another layer of protection. Knowing that IE has opted out of additional security features along with this, and your attack space has gotten larger.

In my opinion, if we want to make sure that the systems are security, it needs to be a multi-pronged approach. 1) it needs to be convenient for the user, 2) it needs to be built into the OS, 3) it needs to be enforced by the applications. Developers are going to need to start writing code that doesn't opt out of DEP (Data Execution Protection) and ASLR(Address Space Layout Randomization), but sometimes that's hard, and we're willing to compromise. We all compromise some, I am sure that I'm not the only one that's hit the "remind me later" button on Acrobat when I'm trying to read a PDF off of a site that I trust. The compromise is what really gets us in trouble i think.

On Windows, the /GS protections aren't always used and can be bypassed (in some cases) even when they are. DEP is not fully supported on some processors and does not have to be enabled for all programs.

OpenBSD has a lot of features to prevent buffer overflow attacks and, as a result, there aren't a lot of OpenBSD exploits.

Linux systems vary. StackGuard (which the /GS protections are based on) can be bypassed. Stack randomization (boot-time or run-time) can be defeated also. ASLR is harder to bypass but it is possible. PaX can be defeated (even aside from the security flaw reported on Bugtraq). Non-exec stack makes exploitation harder, but the return-into-libc method was made specifically to work around this barrier.

I posted a list of papers on writing buffer overflows a couple of weeks ago. Many of the papers in that list deal specifically with defeating the various protections:

Another example of an OS being hardened correctly is an NT box we have here. This thing has been resistant to every thing several of us have tried. When the box we set up, it had just a few services running and was configured in such a way that it didn't respond to an outside box. That is not to say that a person on the inside couldn't get to it. I haven't tried that yet and this gave me that idea. But it boils down to a competent admin keeping up with the latest patches and setting up in a secure manner from the get go.

One last point to ponder. Security seeks to make a target as unattractive as possible. Look at the target house a burglar may go after. He is going to look for old locks or open windows. Something that suggests an easy pick. But if you have newer locks, locked windows, and an alarm, he is going to look for something easier. That is not to say that he couldn't get into the house, but he runs a greater chance of being caught when the next door neighbor is an easier target. Some one will find a way to get in, the trick is to make it more trouble than it is worth.

there are no SPs on this box and I'll try the reboot. Our other NT box has SP6 installed and that has fallen to our attenpts to gain access like nobody's business. Go figure...the SPs that are supposed to make it more secure actually make it less.