Browser Security: Pwned and Exposed

Supposedly secure browsers are making headlines, but not in a good way. Their makers cannot gloss over the security weaknesses any longer.

*

Browser makers should be concerned, very concerned. Last week, a security researcher with software firm AdGuard called out five malicious ad blocking extensions in the Google Chrome Store.

At that point, they had already been installed by at least 20 million users of the Chrome browser. This shouldn’t have come as a big surprise. Many well-documented cases prove that plugins, in general, exacerbate the risks associated with using a locally installed browser.

And annual exploit competitions like last month’s Pwn2Own keep exposing ever more vulnerabilities of supposedly “secure” browsers for the world (malware authors, in particular) to see and study.

At Pwn2Own (sponsored by security vendor Trend Micro), Apple’s Safari browser was hacked by a three bug chain containing a macOS elevation of privilege vulnerability that modified text on a MacBook Pro’s touch bar. And that wasn’t the end of it for Safari.

Another contestant staged a Safari sandbox escape by getting into the browser using a heap buffer underflow as well as an uninitialized stack variable inside the OS which gave it the ability to execute its own code outside of the Safari sandbox.

This is by far not the first successful sandbox breakout, as documented on this blog. But once again, it highlights the reason why – even with sandboxing – the local browser remains the main attack vector: its tight integration with the machine’s operating system.

What’s that browser doing in the background?

Browser makers have only themselves to blame for attracting extra scrutiny and bad press. By engaging in security theatre about their products and throwing up dust to convince one and all how “secure” their browsers are, they try to divert attention from what their software is actually doing (or missing) in the background when connecting to the internet.

The most blatant example of this is Microsoft. The company says that a future release of Windows 10 “will begin testing a change where links clicked on within the Windows Mail app will open in Microsoft Edge.”

This means that even despite a user’s choice of a different default browser, Edge will perform that particular task following a mail-related click.

What’s behind this decision? While we can only assume motivation at this point since the actual modification is yet to be released, it seems likely that Microsoft is trying to beef up its response to emails that contain malware elements. It’s a heavy-handed move to be sure.

Users’ choices don’t seem to have priority in this case. But will opening malicious links in Microsoft’s Edge browser really make the web more secure?

RSA Soundbites: “My browser? What about it?”

Among the reasons that make me wonder: Microsoft has blogged that, at the same time, it is also adding a way to let users bypass Windows Defender Application Guard (WDAG), its sandboxing solution which works through Edge.

In the same blog post, Microsoft announced that with “this release, users can turn on a feature to download files from their WDAG browsing session onto the host file system.

This feature is available in the Windows 10 Enterprise edition and must be turned on. Once the feature is enabled, users will be able to download files into a folder created in their Downloads folder and open all files on the host.”

At closer inspection, that is one scary paragraph. Microsoft wants to give enterprise users the ability to download any file that they encounter onto the organization’s network through the client.

No mention of any enforcement of a group policy or any other kind of restriction to the downloading and file opening process. Not only will the barn door be unlocked – it will be thrown wide open, adorned with a welcome sign.

When the two changes are combined, it becomes rather simple for a user to fall for a socially engineered lure that is crafted to look legitimate in both Mail and Edge. Crafting the lure will be much easier when attackers know which process will be displaying it to the user.

If the user has set (or can be “socially engineered” to set) WDAG so that it is ineffectual, there is now an easy way to drop a malware file onto the target through bamboozling the user into directly downloading it. This kind of insertion greatly simplifies what is required of the malware, since the typical dropper code doesn’t have to be present. The result:

The user becomes the dropper.

Google’s Chrome – the most used regular browser – comes with its own set of security problems that can vex those users who are lucky enough to learn about them before bad things happen on their machine.

One of them is a forced installation of an extension. It’s done by not allowing the user to leave a malware-laced page until the extension is installed. Typically, a redirect is issued by the offending software to keep users out of the normal Chrome extensions page.

The original page is of the form chrome://extensions/, which is changed to chrome://apps/?r=extensions. Extensions won’t be listed on the page the users now land on, so no action can be taken.

Since this is an internal page to Chrome, blocking JavaScript – which is what was causing the action behind the scenes and generates the dialog box that is trying to force things – won’t change the situation since that setting will only apply to external sites.

Even starting Chrome with extensions disabled won’t help after someone has been infected with this extension, since the redirect prevents Chrome from seeing which extensions are active.

The software that initiated the problem had been on the Chrome Store until it was pulled after three weeks of public outcry. It seemed a legitimate download to average users, until it was deleted. In this particular case, Chrome had to go out to all the installations that had been done and pull the offending extension from the browser directly.

It seems rather interesting that Chrome even has that removal capability in the first place, but it seems to.

That malware shouldn’t get through. But it does.

A recent study by Georgetown University’s Security and Software Engineering Research Center [PDF], which is funded by the National Science Foundation, observed that the way Chrome deals with malware is extremely problematical. Chrome will download a file to the user’s machine, even when it has tagged that file as malware.

The user gets a choice in that case not to run it, but some types of malware (like JPEG-based attacks) will cause deleterious effects if they reach the victim machine at all.

This kind of action in Chrome allows a vector of infection to exist that did not have to be present, save for the maker’s bad security choices. (Full disclosure: Authentic8 is an S2ERC industry partner.)

While the makers of regular browsers are still clamoring that theirs are the “most secure” products, alarming incidents like the detection of the fake ad blockers (now finally booted by Google from the Chrome Store) alert more users to a starkly different reality:

Running any browser on a user’s local machine remains a way for malware to gain entry into that machine, and possibly others that are connected to it.

No amount of peripheral dress up by their vendors will change that in a meaningful way. A completely different way to deal with the browsing function is needed to bolster security for users when they access the web.

*

Larry Loeb has been online since uucp "bang" addressing (where the world existed relative to !decvax) and served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He wrote for BYTE magazine, was a senior editor for the launch of WebWeek, and authored books on the Secure Electronic Transaction Internet protocol and "Hack Proofing XML" (his latest). Larry currently writes about cybersecurity for IBM’s SecurityIntelligence as well as Security Now.