Universal ASLR Bypasses And How To Solve Them

Address Space Layout Randomization is an exploit mitigation technique that focuses on preventing Return Oriented Programming attacks. It’s become one of the “must have” tools for a secure program (like DEP) and it’s preset in all modern user-oriented operating systems.

Mitigating ROP is pretty important as most modern exploits take advantage of it. And ASLR would be entirely effective in an ideal world where every single part of address space is randomized and 64bit address space is impossible to bruteforce and heapspray doesn’t exist. We don’t live in that world and there are universal ASLR bypasses for Windows and Linux, heapspray does exist, and the majority of users are stuck in a 32bit address space (and 64bit vanilla ASLR isn’t necessarily impossible to bruteforce).

Windows is actually pretty on top of things with ASLR (as of Windows 8) and /FORCEASLR but there’s always going to be a way around it (unless some things seriously change.)

So what’s the answer?

Well, for non-performance critical applications perhaps a solution like Gadgetless Binaries would be a viable option. Gadgetless binaries would compile code in such a way that an attacker would be unable to make use of static address space instructions to form their attack.

There is a performance hit here so I’m not saying to compile everything with it, but for security critical applications why not? There are specific areas of Windows address space that are loaded in the same exact place every time – why not compile that area with gadgetless binaries and avoid situations like this?

There’s also a somewhat less effective In-Place Code  Randomization technique and even less effective (though still welcome) EAF, which is what Microsoft has implemented.

Perhaps I’m just missing something. Maybe this would require paying out or some such thing but it seems like a great idea to me as ASLR isn’t going to solve every problem. At least not with current implementations (outside of PaX ASLR, which makes use of many other features via Grsecurity to prevent attacks against ASLR).

Sources:

http://iseclab.org/papers/gfree.pdf

EMET v3.0 – What’s New and How To Set It Up

Microsoft has released version 3.0 of EMET (Enhanced Mitigation Experience Toolkit), a must-have security tool for Windows. To summarize my previous post on EMET, it is a lightweight exploit mitigation tookit that forces programs to make use of modern security techniques – simply put it makes programs more secure. This guide will show you how to set EMET up to secure your Windows system without infringing on your program compatibility. I highly recommend you follow this guide and set EMET up accordingly. I’ve included screenshots to make this guide as clear as possible – setup for 3.0 is just a few minutes.

The major changes in EMET 3.0 are the new pre-made profiles, which make setup easier, and the notifier. EMET will now give a notification when it detects an exploit and you can read about the new pre-made profiles later down the page. You can disable the notifier through msconfig.exe or exit it by clicking the EMET icon in your system tray. I suggest you keep it on unless you’re running on a very old system.

EMET has two main interfaces: one to deal with system wide settings and one to deal with application specific settings.

System Settings:

When you open up EMET you’ll see:

Click “Configure System” and you’ll be brought here: (Your settings will look different)

My suggested configuration is:

DEP: Always On

SEHOP: Always On

ASLR: Opt In

What this means is that all programs will be forced to use DEP and SEHOP and programs have the ability to opt into using ASLR. If you are noticing instability you can change the DEP setting to “Opt-Out” or back to “Opt-In” but I strongly recommend you try Always On first. SEHOP can only be set to “Opt-Out” on Windows 7.

That’s all it takes to set EMET up system wide. (And a system reboot, which you can do after following the rest of this guide.)

Note: ATI Drivers 12.6+ are now ASLR compatible. You may want to give ASLR Always On a try!

Application Specific Settings:

EMET 3.0 makes securing individual programs incredibly easy. Click the “Configure Apps” button on the bottom right of the EMET GUI.

You’ll see this:

Go to File -> Import and navigate to /Program Files(86)/EMET/Deployment/Protection Profiles/all.xml and open it through EMET.

This will add a large list of programs, already configured, to your EMET list. You can change this up if you like but right away your system is much more secure. The default settings seem to cover the most important areas.

If you want to add another program just click “Add” and navigate to the .exe.

The highlight of the preconfigured .xml is that all Java executable files as well as your browser and browser plugins are configured to use EMET. These are the most commonly exploited programs and hardening them is a critical step in securing your system.

You may receive a notification from the EMET Notifier. A new feature to 3.0 that lets you know which security mitigation was just used to prevent an exploit.

 

 

 

That’s all there is to setting up EMET. This should take just a few minutes (including time to download) and it’s the first step to securing Windows. I hope this guide helped.

Tip: If you notice an EMET’d program acting out try disabling EAF. It can cause issues.

You can download EMET from:

https://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx?Redirected=true

Note:

It is worth stating that just because you use EMET does not mean you can forego patching. While EMET is an incredible tool for securing Windows it is not a silver bullet, you must keep your system up to date.

Sources:

http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx

Is Ubuntu Really More Secure Than Windows 7?

Is Ubuntu Really More Secure Than Windows 7?

A lot of people look at Linux because they hear that it’s more secure, among other things. Is there truth to this? In my opinion, yes, and it’s a very complicated subject. I’m only going to touch on a few aspects of operating systems here but you should walk a way with a good idea about whether or not Linux is more secure than Windows.

Ubuntu is one of, if not the most used user-oriented Linux distros. The comparison to Windows 7 (the most widely used user Windows OS) is inevitable. While most of this applies to Linux in general I’m singling out Ubuntu specifically due to market share, userbase, and a particular feature I talk about shortly at the end.

Why Windows 7 Is Secure
I’m not going to go into why Windows XP is insecure but I’ll explain how Vista and 7 improved security. There are definitely a few significant changes that should be noted so that we can compare those changes to Linux implementations.

The first really big change in Windows 7 is ASLR and SEHOP. ASLR is Address Space Layout Randomization and it essentially makes it difficult for an attacker to use a programs own code to execute what they want. SEHOP is a technique that specifically deals with SEH overwrites ie: a specific type of overflow that targets the Structured Exception Handler. SEH overwrites made up 20% of the exploits in the Metasploit Framework at one point. These two techniques directly address highly exploitable features of the OS.

The next change is adding a Windows Update that doesn’t completely suck. XP made you go through IE, it was awful and (I don’t know about you guys) it never worked well for me. The new updater is simple, independent, and far less buggy in my experience.

And then there’s the change in Microsoft. They realized people didn’t like getting infections and they’ve made a huge shift from being insanely slow to patch to being pretty proactive about it. This newfound ability to get patches out quickly combined with an updater that isn’t completely awful is really great for users and is probably one of the largest reasons why we’ve started to see OS exploits drop and 3rd party exploits rise.

Lastly there is the under-appreciated Mandatory Integrity Access Control. Windows 7 has segregated the file system into layers primarily consisting of “Low”, “Medium”, and “High”, integrity files and folders. Programs running at low can’t write to medium/ high, programs running at medium can’t write to high, and programs running at high can write anywhere. It’s very powerful and it’s the basis of the Chrome and IE9 sandboxes.

Why Ubuntu Does It Better
I won’t go into OSS vs CSS in this post. Maybe if I get really really bored some day if anyone actually ever reads this thing. I also will not go into “security through obscurity” as it’s not actually a real thing. I’m going to focus on some other points, which are more easily substantiated.

The first real boon to Ubuntu’s security is package management. Probably my favorite part about running Linux is that I don’t have to do a thing to keep the system up to date. On Windows it’s “Run Flash Updater… ok done… run Java updater… ok done… run Windows updater… etc” but on Linux it’s all handled in one place. I click “Update” (or nothing at all, it’ll do it on its own eventually) and my browser, plugins, IM client, IRC client, and operating system (and anything else) are all patched up. Consider the significance of this – the Flashback trojan infected 700,000 OSX systems using a vulnerability that had been patched *months* before.

Where Windows has Mandatory Integrity Access Control (MIAC) Ubuntu has Apparmor. Well, sorta. Ubuntu has a set of permissions that follow DAC policies. What Ubuntu also has is a MAC implementation that allows for incredibly finely grained access control. On Windows there are very few programs that actually run at low integrity, on Linux virtually every application can run with Apparmor and there are a few that do by default – specifically system services. Apparmor is incredibly powerful because almost anyone can learn to use it – creating a profile takes minutes in most cases and it reinforces the already fair access control. MIAC can’t touch Apparmor – it’s not even close.

Ubuntu is actually fairly unique among distros as it’s one of the first to implement the new Mode 2 Seccomp Filters. A new way to limit visible kernel attack surface by only allowing syscalls on a whitelist basis. This is a new feature so it’s not easy to gauge but, judging by the principal, it should pair incredibly well with other security mechanisms like Apparmor by preventing privilege escalation.

So there you have it. Why Ubuntu is more secure than Windows 7.

What Needs To Be Said

There’s no actual way to say X is more secure than Y. I know, I just typed this whole thing out but we can only make a best guess; there is no objective measure of security. I can’t say that powerful ASLR is more important than strong malicious file detection without significant research to back that up, and even then it’s limited. What I can do is use my own judgement to take the above information (among other things) to come to a conclusion and do my best to present this to you.

There’s a lot more to all of this than what I’ve posted and there are a lot of opinions about it. This isn’t some huge research paper attempting to provide definitive answers, it’s just me, bored, comparing two operating systems. Windows 8 is entirely outside of the scope of this as it includes many new security features.

I could write a lot more like how Linux is inherently more secure because blah blah blah open source blah blah blah kernel blah blah blah but I won’t. Not tonight. Maybe some other night I’ll do an “Is Linux more secure than Windows?” blog post that goes in depth into things like ASLR implementations (mmap is randomized, virtualalloc isn’t), NX(execshield, emet), smartscreen, DAC vs MAC, etc.

Sources:
https://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx
https://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx
https://wiki.ubuntu.com/Security/Features