Chrome Stable Shipping With Vulnerable Flash Player

Google Chrome 23 was just released to the stable channel with some notable security fixes. It’s also shipping out with a vulnerable Flash Player. Chrome bundles its PPAPI Flash Player into updates, which usually means users are patched more quickly or even before official patches are out. The PPAPI Flash plugin also runs in a very restrictive sandbox, on Windows it runs at an Untrusted Integrity Level with job tokens applied to it, and on Linux it runs with the BPF Sandbox among other things.

While this typically means users are ahead of patches, in this case Google fell behind. Users shouldn’t worry too much, even if they did land on an exploit page for the vulnerability (and I don’t believe any are currently in the wild) the sandbox is very strong and they’d be protected from infection.

Google will be releasing the latest patched version shortly.

0-Day Exploit Bypasses Adobe Reader Sandbox

A youtube video demonstrates an attack against Adobe’s PDF Reader – something that used to be completely mainstream, boring. But what makes this interesting is that it also bypasses the Adobe Reader sandbox, based on the sandbox used by Google Chrome, and the exploit doesn’t rely on Javascript.

Adobe Reader implemented a sandbox of similar architecture to Google Chrome, using a low integrity process to handle untrusted code and a broker process to make security decisions. This attack bypasses the Adobe Reader sandbox entirely and, unlike most Adobe Reader exploits, doesn’t require JavaScript to work.

Attacks like this are likely to become more common. As programs make use of sandboxes it becomes necessary for attackers to break out of those sandboxes to further monetize the system.

Adobe Reader has always been a popular program to exploit due to the nature of PDF and the popularity of the software. It seems attackers aren’t giving up just because of a sandbox, though it’s clear that the Adobe Reader Sandbox has reduced attacks in the wild.

The exploit, which is being sold on the black market for 30,000-50,000 dollars is already incorporated into the popular Blackhole Exploit Kit. Blackhole Exploit Kit is a very popular way for attackers to distribute malware such as Zeus (a popular piece of malware that steals bank info) so it’s best to be wary while opening PDFs until a patch is out.

For protection against this exploit I suggest setting up EMET. Click here to read how.

 

Update: Adobe is now in contact with Group-IB and hopefully there will be a fix out soon.

I Think It’s About Time Oracle Steps It Up

A lot of websites have started to flat out state that Java needs to be uninstalled on most users computers. And they’re not wrong – Java is exploited a ton and sandbox escape exploits in the JRE can lead to attacks that hit users running Windows, OSX, and even Linux. And stopping these attacks as a Windows/OSX user is really difficult (Linux makes it pretty easy).

Oracle needs to be more proactive. Honestly, I don’t see why they’re lagging behind in web security – for God sake Adobe’s even doing better, significantly better.

Oracle needs to implement modern hardening techniques into their JIT and they need to redesign the JRE web plugin to work at Low Integrity (Windows sandbox). Adobe has done this and it’s paid off – Flash isn’t the security hole it used to be, I don’t worry at all about Flash exploits anymore as a Chrome user.

Most attacks against Oracle’s JRE aren’t buffer overflows, they’re simple applets that run code on the system. They break out of the JRE sandbox (all the time) and get access to a large part of the system. Due to the nature of how code runs in the JRE (JIT’d code) things like DEP and ASLR aren’t nearly as important. The key here is to contain the exploit with something built into the operating system.

Hopefully with Windows 8 we’ll see AppContainer usage for Oracle’s JRE. The details on AppContainer aren’t really clear yet but it may provide something decent.

Java just isn’t going to get used if people are afraid to have it installed, and that sucks because it’s actually a really cool language.

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

A Tip For Those Looking To Lock Down Windows

In my last post I explaining why I won’t be buying ATI until they fix their insecure drivers. This reminded me that Windows does actually have a little-known ability to run the entire system with ASLR enabled. Of course, this can lead to instability and in the case of those of you running ATI cards you will BSOD immediately but if you’re willing to take the risk it’s one more way to lock down Windows.

First, I suggest you take a look at this guide for securing Windows and this guide for setting up EMET.

This short guide will get your ASLR Always On setting enabled in the EMET User Interface.

If you’ve followed the guides you can:

1) Open Regedit

2) Navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftEMET

3) Change ‘EnableUnsafeSettings’ to ‘1’

4) Go to your EMET GUI and System Settings – turn ASLR to Always On. If it isn’t there you may need to reboot first.

5) Reboot

Your system might crash in which case you need to go into Safe Mode and disable this. It should go without saying that this risk falls on you, I’ll feel pretty bad if I break your computer but there’s fair warning here.

So now instead of applications having to explicitly opt into using ASLR on Windows your entire system should be running with it. This will probably break a few programs but if it works, great, you’re somewhat potentially more secure.

Browser Wars – Everyone Else Does It

Browser Wars – Security Style

Browser wars are monthly blogs (typically following the latest release of a browser) that basically pit the latest versions of todays browsers against each other. It’s kinda lame and I feel like a tool for doing it but I’m also really bored and I think browsers in the context of security are awesome.

So, let’s start.

What Makes A Program Secure?
In an ideal world we humans would be perfect and our code would be perfect and vulnerabilities wouldn’t exist. This is not an ideal world and we are not perfect nor is our code. Vulnerabilities do exist and for the foreseeable future this will not change. So what do we do to secure programs if they’ll always be full of holes? We accept that those holes are there and we make it as hard for hackers to make use of them as we can. There are various ways to accomplish this.

So What About Browsers?
Browsers aren’t typical programs. They’re fast paced, constantly changing, plugin-filled conduits to the wide open internet. By design they take in untrusted code. They’re just dangerous and that’s why they’re so great to look at for security.

Internet Explorer 9
Internet Explorer has laughable security, right? I mean, hey, IE6 on XP was terrible and nothing’s changed. Not exactly. Microsoft has learned from their (massive, gaping) mistakes and then some. IE9 is no IE6 by any stretch of the imagination. It’s got a multiprocess architecture that allows for tabs to be separated into low-rights processes, which means that an exploit in a tab is confined to that low-rights process.
On top of that IE9 has a new version of SmartScreen, a URL and File Blacklist based on “File Reputation” and heuristics. There hasn’t been a formal study other than the one by NSS Labs on this that I know of but NSS Labs gave a remarkable score of blocking 96+% socially engineered malware (compared to trivial scores hovering around 13% for other browsers.)
As I recall Adobe Flash also runs at low integrity when used with IE9.
The low rights sandbox and smart screen make IE9 a very secure browser.
IE is Windows only and closed source.

Mozilla Firefox 4.0+
The Firefox browser, which is developed by Mozilla, is a free and open source browser that’s been very successful. In terms of customizing UI and features Firefox is top notch and it blows Chrome and IE9 out of the water in that respect. In terms of security it is… lacking.
Firefox does implement modern techniques like ASLR, DEP, and SEHOP and it even forces ASLR on toolbar binaries.
It also makes use of the Safe Browsing API 1.0, which (last I checked) blocks something like 15-20% of malware downloads.
Firefox does not implement any “extraordinary” security measures. There is no sandbox, there is no special file reputation whatever or special memory hardening technique. There’s just nothing that really stands out about Firefox.
Firefox users are able to make use of the NoScript extension, which is potentially a really great tool, but it’s not exactly accessible for the average user and I’m partial to security features that don’t bug me.
Linux users can make use of a “whole-browser” sandbox via Apparmor/LSM. A profile is provided by default on Ubuntu but it may take some tweaking, I highly recommend you check out AppArmor for your browser – check out my guide here.

All in all, I want to love Firefox, but I can’t really give it a ton of credit here.

Google Chrome X.XXX.XX.XXXX+ (or whatever)
Google Chrome is the (relatively) new player in the browser market. At only 3 and change years old it’s had a pretty impressive start, now holding market share close to Firefox. Chrome is based on Chromium, which is an entirely open source project – the difference being that Chrome packages Flash, a PDF viewer, and an update manager (on Linux it also packages support for closed codecs.)
It uses the Safe Browsing API 2.0, which includes a file reputation module. I think NSS  Labs puts it up around 40% block rate. Again, there hasn’t been what I would consider a formal study on this.
Chrome’s main feature is a sophisticated sandbox based on the Windows integrity access control and job tokens. It is similar in architecture to IE9’s sandbox but the restrictions are much tighter, with the renderer having no file access and most of the browser running at absolute lowest rights possible  on Windows.
Chrome also sandboxes the GPU process and all extensions. Each has its own separate process.
Chrome sandboxes the Flash plugin (responsible for a large number of infections) and will soon include a much more powerful sandbox for Flash via the PPAPI(nterface, which is in beta 20.)
On Linux Chrome makes use of a namespace and chroot sandbox as well as the seccomp mode 2 filters. This allows for a strong sandbox, it’s very tight. Apparmor profiles exist for it, which are useful as they’ll even restrict the zygote process. The weakness is that the zygote process must be setUID, which is why an apparmor profile is suggested.
Chrome also limits inter process communication between it and the Java plugin, which can potentially prevent Java exploitation though it’s uncommon.

Opera 11.x
Opera is the lonely browser. On a good day it gets 4% of the market. It’s got something of a cult following and boasts pretty nice performance and a ton of features built in. As with Firefox it’s pretty lacking when it comes to security.
Opera is closed source and there isn’t a ton of documentation for security. There does not seem to be anything special about it.
No sandbox (there might be one on Linux actually but I’m not sure), not too great at filtering malware (I think NSS labs had it at 0-5%, again there needs to be more formal studies here.)
Closed source doesn’t inspire confidence either frankly.

I can’t really suggest Opera if you’re looking for security.

Conclusion:
I guess I should order them or rank them or something – answer that “Which browser is most secure?” question. I won’t try to apply anything numeric to this, that would be dumb, the system is basically an amalgamation of the above and my own personal beliefs on security.

Greatest to least: Chrome, IE9, Firefox, Opera.

I think it’s pretty close between Chrome and IE9. Firefox with NoScript and Apparmor is a pretty secure browser but for a defense in depth approach I’ve got to go with Chrome. It’s dependent on what you’re trying to secure against – when it comes to system compromise you’ll want Chrome but if it’s about preventing XSS/Clickjacking Firefox with NoScript is the way to go.

There you have it. My opinion.

I left a lot out. JIT Hardening isn’t something worth measuring as the javascript VMs all work pretty differently and they just don’t apply. I didn’t both going into ASLR or other mitigation techniques, all of the browsers have these by default at this point and the differences are subtly and in the implementation. I didn’t go into privacy, incognito/ private browsing modes, not much into extensions (this could be its own post), and some other stuff to. So consider this a very simple rundown on security. Even if I were to include everything the results would be the same, you’d just be better informed.

I’m also not going into IE10, which will include some fairly significant security improvements.

Choose the browser that is right for you. Maybe that’s the one that you think is most secure, maybe it’s the one with the UI you like best, or really any other reason. It’s your choice and it’s entirely up to you.
Sources:
http://www.accuvant.com/blog/2011/12/05/which-web-browser-is-most-secured
https://www.nsslabs.com/assets/noreg-reports/2011/nss%20labs_q3_2011_browsersem%20GLOBAL-FINAL.pdf [PDF]
http://windows.microsoft.com/en-US/windows-vista/What-does-Internet-Explorer-protected-mode-do

Chrome, Internet Explorer, Firefox Response To ‘Exploit’

A recent blogpost showed how Chrome, Internet Explorer 9, and Firefox are all vulnerable to a specific bug that can be used to trick the user into downloading a file when they meant to download something else.

 the fake flash11_updater.exe download supposedly served from adobe.com is, in reality, supplied by the attacker

The bug isn’t really the issue here, though. I mean, it’s definitely useful for social engineering and I can think of a millions ways that I could infect people with this but what I’d like to draw attention to is the response given by the browser vendors.

The response to this has apparently been:

  • Chrome: reported March 30 (bug 121259). Fix planned, but no specific date set.
  • Internet Explorer: reported April 1 (case 12372gd). The vendor will not address the issue with a security patch for any current version of MSIE.
  • Firefox: reported March 30 (bug 741050). No commitment to fix at this point

I think that says a lot about browser security. None of them have fixed it and only Chrome has stated they ever plan to, though they’ve given no date. At least Firefox and Chrome gave some discussion.

Think about it this way. If I were to post “Hey guys, update Adobe Flash Player, big security update!” and I linked to the Flash page with the download started I bet a lot of you would install it without a second thought. I’d probably fall for it too if it were linked from a forum I frequent.

This isn’t the biggest security flaw ever, it’s useful for social engineering and there’s definitely potential here but it’s not going to lead to millions of infections (on its own at least.) I just think it’s interesting to see how vendors see ‘low priority’ security flaws.

Check out the proof of concept here. Tell me this wouldn’t fool you if I’d linked to it saying that it was a security update for Flash. Be honest.

Sources:

http://lcamtuf.blogspot.com/2012/05/yes-you-can-have-fun-with-downloads.html

EMET – A Windows Security Tool That Everyone Should Use

Techniques like ASLR and DEP have made exploitation of modern software more difficult. And yet many programs still don’t make use of them. Why? Well, sometimes it’s a matter of compatibility but very often it’s simply a matter of the developer not knowing or not caring enough to implement them.

EMET sets out to fix this.

There are very few programs that I think belong on every single computer. EMET is one of those few.

What is it?

EMET is the Enhanced Mitigation Experience Toolkit and it’s pretty damn cool. The goal of EMET is to prevent programs from being exploited by forcing them to make use of modern mitigation techniques (EAF, SEHOP, ASLR, DEP, HeapSpray, Bottom Up Randomization.)

The Good

EMET attempts to bring insecure programs like Java (which is the most exploited piece of software for Windows users) up to speed in terms of security. By running Java with EMET you can prevent a ton of exploits that would have otherwise led to infection. You can also run your browser with EMET to prevent Flash/ browser exploits.

EMET also uses virtually no resources. EMET.dll is something like 44kb and that’s all that’s loaded into programs. The mitigation techniques should have a negligible effect on performance as well.

Compatibility is easy to maintain as EMET can be used on a per-program basis. I suggest that you run your PDF viewer and Java with EMET and consider running your browser as well.

Windows XP users should be downloading EMET as soon as possible. XP doesn’t have any form of ASLR but EMET will provide EAF, which is another ROP mitigation (though less effective.)

The Bad

EMET is not a replacement for an antivirus. It offers absolutely no detection of malware or malicious activity – its only goal is to prevent exploitation.

Even with all of those mitigation techniques there are ways around them; DEP and ASLR just don’t apply to every situation ie: JIT Spraying, which needs a whole separate class of mitigation. EMET drives up the cost of exploit, it doesn’t eliminate the threat.

Some of the techniques like EAF and HeapSpray are also easily bypassed, they’re more for defeating automated attacks, which is still valuable since that’s what the average user will come across.

There are potential compatibility issues with EMET. Very old programs can’t handle DEP and they’ll potentially break even if you just install EMET. It sucks. I suggest you contact the developer and remove EMET in the meantime.

It should be plain to see why EMET is such a significant security tool. Forcing horribly insecure programs like Java to start acting like modern software is probably the most important first step in securing Windows. EMET is a must have, whether you’re on XP, Vista, or 7.

I’ll be posting a guide with screenshots on how to set up EMET very soon.

Grab EMET Here:

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