PDF.js For Chrome – It Works!

edit: Now available on the Chrome Web Store: (use this! not the one I link later from Opera)

https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm?utm_source=chrome-ntp-icon

So Opera recently came out with a PDF.js extension for their latest Blink build of the browser. I kinda thought, hey, Opera and Chrome aren’t all that different anymore… maybe it’ll work? So I downloaded the file from:

https://addons.opera.com/en/extensions/details/pdf-viewer/

And I got a pdf-viewer-0.8.169-1.nex and I changed the file extension to pdf-viewer-0.8.169-1.crx. 

I then launched Chrome with the command flag –easy-off-store-extension-install and opened up chrome://extensions. I dragged the .crx file onto the page, and voila – it installed!

So then I opened up the first PDF I found on Google and…

PDFjschromeSuccess! PDF.js now works in Chrome, with just a little bit of work. The extension almost certainly won’t autoupdate, though perhaps it will. No idea. But there you have it.

One of the benefits of PDF.js is that your entire PDF “program” is implemented in Javascript. Chrome runs Javascript in an incredibly tight sandbox in its renderer, so attacks using PDFs will be restricted to that sandbox.

So there you have it. Chrome now has PDF.js, and it’s available on Firefox and Opera as well. For more on PDF.js in Chrome, see my earlier post.

 

Why You Should Use NoScript

It’s commonly said that the browser and its plugins are the number one attack point for the average user. So locking down the browser is obviously key to maintaining a secure system. I’ve written a guide for Firefox as well as Chrome, but I want to take a post to really focus on the NoScript extension for Firefox.

NoScript is an open source project that aims to secure the browser. It prevents code from executing in the browser, such as Java, Flash, Javascript, Silverlight, or any other plugin, and it provides a few other features as well. It’s probably the number one best way to secure Firefox.

NoScript has three main modes:

1) Globally deny all scripts

Scripts on any webpage are blocked until whitelisted.

2) Allow Top Level Domain

Scripts from the top level domain (ie: the website your on, no third party content) are allowed to run, all others blocked.

3) Allow all scripts globally

In terms of security, it pretty much goes 1 > 2 > 3.

By blocking all scripts you prevent any attack that needs to make use of Javascript, Java, Flash, or another plugin. That covers the absolute vast majority of attacks we see against users.

NoScript’s default setting, deny all scripts, may be a bit overbearing for some. But even if you can’t handle having the default setting I still suggest installing NoScript and leaving it on 2 or 3, which are more manageable but still provide security features.

Even if you allow all scripts globally NoScript will do the following:

XSS Filter

NoScript includes its own XSS Filter, and it’s pretty great. XSS (Cross Site Scripting) is considered one of the most dangerous threats to security and NoScript provides a very strict filter, stricter than browsers include. Even if you whitelist globally you benefit from the XSS Filter.

HSTS

NoScript can also force HTTPS redirection for websites, preventing MITM attacks on specific sites. NoScript also has Hyper Strict Transport Security support, which means that websites can tell it to always enforce HTTPS and it will. This feature is also present even with all scripts allowed.

ClearClick

NoScript provides Clickjacking protection via ClearClick. Clickjacking is a type of attack that takes advantage of invisible content. You think you’re clicking one thing but you’re actually clicking another. ClearClick reveals hidden attributes on a page any time you interact with it, and blocks that interaction. This defeats Clickjacking independently of Javascript/ iFrame blocking.

ABE

ABE, or Application Boundary Enforcement acts as a broker to determine whether separate web applications should be given specific rights – it provides isolation at the web applications level.

 

So it’s clear that even with NoScript set to Globally Allow you’re much better off than a vanilla Firefox. I highly recommend that if you’re a Firefox user you make use of NoScript at its default setting, but just having it installed for any of the above features is a good idea. It’s a great tool for preventing tracking and ensuring privacy on the web (there’s a reason why TOR uses NoScript!) as well as preventing exploitation.

Banking Online? Firefox With NoScript Is Your Best Bet

If you’re asking the question “How do I securely do my banking online?” you’re one of many. Banking is something we used to do upfront and in person (or so I’m told, before my time) but now that the web has allowed access to our accounts from any location we have to ask how to do something so sensitive in a secure manor. This article will be a short guide to secure online banking.

Normally I say that Chrome is a secure browser for the average user, but it’s a different kind of secure. its sandbox aims to do things more relevant to system infection but not web-based attacks. In terms of web security, preventing CSRF, XSS, and the like – the types of attacks most directly related to online banking – I think Firefox with NoScript takes the cake. NoScript is the only program that’s proven to prevent XSS in the most situations, it’s the only program with ClickJacking prevention that’s worth anything, protection against SVG keylogging, and so many other things, and for banking you want to isolate and restrict the website you’re interacting as much as possible.

There are a few other things you’ll want to do before setting up Firefox if you’re planning on banking online:

1) Make sure you are on a secure network. A secure network is one using WPA2 encryption with a strong 12 character password (or larger) that only you know (assuming wireless).

2) Make sure your system is completely up to date. Keeping intruders out starts with patching. The browser, operating system, and your plugins are key here.

3) If you’re using Linux Ubuntu enable AppArmor for Firefox (sudo aa-enforce /etc/apparmor.d/*firefox*) – other distros may use other LSM.

4) Windows users should follow my quick guide to securing Windows.

After that it’s a matter of installing two key extensions:

1) NoScript. In its default configuration it’s secure. [NoScript.com]

2) HTTPS-Everywhere. [HTTPS-Everywhere]

Only whitelist websites that you know you can trust or (for a higher level of security) keep a separate Firefox profile just for banking with its own whitelist of just banking websites.

Never do your online banking while also using another website in another tab/ window and if you use an antivirus, update it, and run a scan before you use the bank website.

If you follow these instructions you’re making an attackers job much more difficult.

NSS Labs Study Finds Internet Explorer Most Secure Against Click Fraud

An NSS Labs study conducted over 175 days has found that Internet Explorer is the most secure browser when it comes to protecting against Click Fraud.

Key findings from the NSS Labs report include:

  • Click fraud itself causes minimal direct harm to the typical end user as the ultimate target is the ad buyer.
  • Consumer and corporate users, however, are infected by additional malware as a by-product of click fraud installation.
  • Click fraud catch rates are Chrome 1.6%, Firefox 0.8%, Internet Explorer 96.6%, and Safari 0.7%.
  • Services are available that may help ad buyers identify click fraud.  However, service contracts with ad networks may contain clauses that restrict ad buyers’ ability to recover damages for click fraud.
  • The average lifespan of a click fraud URL was 32 hours with over 50% expiring within 54 hours.

The results show Internet Explorer ahead by an incredibly sizable portion – leaving Chrome in second place at a measly 1.6%, Firefox at .8%, and Safar at .7%.

Click Fraud is a type of attack that really hits advertisers, not so much the users. That’s why it’s so surprising that Chrome, a product driven by Google, is receiving such a poor score.

I’m also not about to call NSS labs out but they sure do seem to have a lot of reports indicating Internet Explorer is the most secure browser or rather they only seem to release reports about things that IE excels at (and often by massive margins). It would be really nice to have another independent research group test things out. When Accuvant did a study comparing browsers (NOT that this study was unbias) they found basically no difference between IE and Chrome in terms of detecting malware, which was contrary to a study by NSS labs that showed IE outperforming Chrome by about 60%.

Take it with a grain of salt but it’s worth noting.

Comparing PPAPI Flash To Firefox Flash Sandbox

Chrome 21 hit Windows a few days ago and I’ve been meaning to write a post letting users know that they should know be running the PPAPI Flash Plugin by default (check chrome://plugins), which enables a far more restrictive sandbox.

How much stronger is this sandbox? IBM has written a wonderful whitepaper about it comparing the Firefox NPAPI Flash Sandbox, Chrome NPAPI Flash Sandbox, and the newly rolled out Chrome PPAPI Flash Sandbox.

The PPAPI Sandbox adds a number of restrictions. Here’s a few screenshots of the presentation that highlight some important areas.

Image

Image

Image

Image

Image

Image

Image

 

As you can see the Pepper Flash is significantly more secure than the NPAPI Plugin used previously and currently. It has considerably reduced read access, write access, and registry access as well as stronger and more restrictive job tokens.

The first sandbox bypass for Chrome by Vupen used the Flash plugin because the sandbox for it was the weak link. Firefox’s sandbox has improved somewhat over the old Chrome sandbox but the latest iteration, Pepper, is much stronger than either of the two.

Flash exploits in the wild are going to drop significantly, just as they did with Adobe reader.

Just Set Up A Computer For Someone Who’s Never Had One

I’ve just finished setting up a computer for someone who’s only ever had a work computer, which isn’t connected to the internet. They share a laptop with someone but rarely use it.

Today I helped them pick out a system, Dell, and I got them started. One really interesting thing I saw was that Dell packaged the Java plugin… an out of date Java plugin. So right off the start my friend was running Java 7.1 (wtf?), which is something like 3 patches behind.

So, naturally, I updated it and installed EMET, which I set Java to use (and changed default Windows 7 settings for DEP Always On). The system also came with Webroot security. I actually think Webroot’s pretty good but I don’t have enough personal use with it to trust it and I’m pretty sure it isn’t free, which means it’ll bug my friend in a few months and he’ll be at risk.

So I removed Webroot and put in Microsoft Security Essentials. Why? For the low false positives and direct Microsoft support.

I also put Google Chrome on the system. I can not explain to someone that they need to use NoScript when they’ve never used a personal computer – they will hate me. Chrome is the only way I can keep him secure without ever getting in his way. The Chrome sandbox is “silent” and that’s really important as this guy is likely very vulnerable to social engineering having never been exposed to it in the past.

I think he’ll be fine. With 5 minutes I’ve set his system up in such a way as to be very difficult to exploit through the most common ways (browser, plugins) and Microsoft Security Essentials is good enough and quiet enough that he should be able to trust it.

The Last Day Of Firefox

Well, as I’d promised I used Firefox and only Firefox for a week. This is the last day of use and I do have to say I’ll be going back to Chrome.

I liked Firefox but there’s nothing that really stands out. The best thing is that I can’t close pinned tabs. That’s really the best part of it right now.

But the startup is slow because of the pinned tabs and Firefox as a whole is definitely slower than Chrome in terms of UI responsiveness and page loads. WordPress is a really good example of this, it’s nearly instant on Chrome but Firefox hiccups.

I like NoScript too but there’s no way I would run with Scripts Globally Blocked — huge pain in the ass. Without that there are still protections but not nearly as many. While the Globally Blocked would provide significant security the Globally Allowed does much less – the part that stands out is ClearClick, which is meant to protect against clickjacking.

While I’ll miss NoScript I don’t think that Globally Allowed protects me enough to make it worth it.

NoScript v Sandbox

Where Firefox has NoScript Chrome has a Sandbox. The two aim to do very different features.

NoScript protects against attacks like XSS, clickjacking, and it’ll block websites from loading up Javascript, Plugins, WebGL, which can be used to exploit the machine.

Chrome’s sandbox is meant to protect against attacks that would use RCE to compromise a system. By locking the browser into a strict environment malicious code is not able to interact dangerously with the system.

The difference is that NoScript really protects the browser session itself and Chrome protects the system. So for something like getting online to bank it might be better to go with Firefox with NoScript and HTTPS-Everywhere but if you’re worried about visiting an exploit page that’ll try a drive-by you’ll likely want Chrome.

Thankfully on Linux you can use AppArmor or SELinux or another LSM to restrict Firefox but the Chrome sandbox goes beyond LSM.

So for my personal use I find Chrome to be the more secure option. For specific tasks like online banking I might consider Firefox.

All in all it’s a matter of multiple factors. Performance, security, and stability. I actually had no crashes or glitches with Firefox or Flash in Firefox, which surprised me. I rarely have issues with Chrome either but I do on occasion. In terms of performance though there’s no question and for me personally Chrome is providing the security I want.

So it’s back to Chrome for me.

I’ll see if I can get my friend from Moz to write something, I’m sure he’s dying to get Chrome off of his system.

Day One Of Firefox – Nostalgia

I posted about how I’m now using Firefox thanks to a friend at Mozilla. We agreed that I would use only Firefox for one week and he would use only Chrome for one week.

Well, I installed Firefox today and I really do remember why I loved it years ago. Nostalgia is in full effect.

A few highlights:

  1. Firefox has improved performance significantly since I last tried it. The difference is noticeable for some page loads.
  2. I have most of my extensions, like LastPass and HTTPS-Everywhere and a cool twitter extension.
  3. I have extensions I couldn’t get on Chrome like NoScript and Convergence.
  4. The default UI is easy to get used to.

My current issues:

  1. Even though page performance is much better, for whatever reason when I log into LastPass it’s *much* slower and Firefox halts. I think this is an issue with the single-process architecture. On Chrome the extension itself will freeze but I can still browser without issue – on Firefox the whole process gets brought down. I use about 35,000 rounds of hashing. On Chrome this is about 3-4 seconds and on Firefox it’s more like 10 and the browser is unusable until it’s done – big issue. Chrome in general is noticeably faster – sometimes it’s more obvious than other times but it is, at least for me (and I’m sure on various hardware it’s more/ less noticeable) there can be a big difference.
  2. Incognito browsing/ private browsing can’t compete with Chrome’s implementation. The biggest issue for me is that I can’t do both at the same time (though there’s an extension for this I believe), which is something I do constantly with Chrome, keeping the windows side by side. The other issue is that extensions run in incognito when I don’t need/ want them to.
  3. Tab behavior by default is a pain. I like shrinking tabs, not a bar that I have to scroll through. This isn’t that big of a deal, just a little peeve that helped get me using Chrome.

I’m enjoying getting to use Firefox as it’s been a while and I’ve forgotten so much. I’m sure as time goes on I’ll have more good things to report and more to complain about.

Adobe Flash For Firefox Gets A Sandbox

Adobe Flash 11.3 for Firefox now runs in a sandbox! Yay. It’s not super strong, it should be virtually identical in nature to Chrome’s NPAPI sandbox, which Vupen broke out of twice. Still, this moves the cost of Flash exploitation far above what it used to be.

Chrome users will also be pleased to know that the PPAPI plugin has moved to 11.3 and it is really stable. I’m running it full time and youtube and google music run flawlessly.

So it’s a good day for security. You can expect Flash exploits in the wild to wither away because all three major browsers now sandbox it. Where will hackers go? Well… either we’ll start seeing more sophisticated attacks on the Windows system (kernel exploits, yada yada) or we’ll start seeing attacks on other plugins like… Java.

My advice… either EMET Java or uninstall it. It’s just gonna get worse for that plugin.

PDF.js And Chrome – A Match Made In Heaven?

PDF.js is a Mozilla project built with the purpose of reducing trusted code by having PDF files handled by the Javascript renderer. This means that instead of having a separate plugin built in C++ there’s just the same old javascript renderer, no need to build on potentially exploitable code.

It’s a great idea and it works on a very simple principal that should always be held true – reduce attack surface where possible.

This isn’t some kinda amazing security thing though. JavaScript renderer exploits happen all the time, in fact that’s probably where they’re most likely to happen. Firefox also doesn’t implement some important mitigation techniques for JIT hardening (things like ASLR/DEP don’t apply here) though that’s more complex and when you look at their architecture it’s difficult to really say how important it is.

As PDF.js is entirely in Javascript it can theoretically run in any browser that supports Javascript, like Chrome.

The renderer is the ‘exposed code’ in this situation and Chrome runs its renderer at Untrusted Integrity. That means it has no file access. So even if a PDF exploits PDF.js in Chrome it’s trapped in the most restricted part of the browser and there’s really nothing it can do – it can’t read or write anywhere so even in-browser attacks are limited.

As it stands PDF.js works in Chrome but there’s no extension/plugin for it yet. Someone get on that – I want.