2015-06-15

CVE-2015-1261 and the state of modern mobile browser UIs

Usability is a notoriously difficult problem on mobile devices. The screen estate is extremely limited, buttons have to be large to make them touch-friendly, there's always a finger or two in the way, and still the user expects a more straight-forward experience than on the desktop. Developers also tend to prioritize usability over things like, say, security—which leads to all kinds of interesting problems.

For example, at the moment, it's not possible to view the details of an SSL server certificate in the stable release of Google Chrome for Android. It used to be, sure, but the feature was removed because it wasn't usable. It was replaced with a page info popup that adds noting you couldn't already see from the omnibox: it simply states the current URL and whether or not Chrome considers the server's SSL certificate valid. Nothing else.

And, because of CVE-2015-1261, it was a bit worse than nothing. Because, well, you could do this:


The screenshot above is from Chrome for Android version 40, showing the page info popup. That's the popup window that opens when you tap on the green lock on an SSL-protected page. And in case it isn't obvious, the entire "warning" part is arbitrary attacker-injected content. Including the icons. Here's what was happening:

Normally, Chrome will encode all special characters, like spaces and newlines, if you try to enter them in a URL. They just turn into %20s, %0As, %0Ds, and the like, automatically. There's an exception to that, though; the fragment part. No extra encoding is done on anything passed in the URL fragment, so it's really easy to mess something up.

Well, in Chrome, they messed it up in the page info popup. The URL was shown as-is and allowed to wrap, and the popup even displayed emoji correctly. That's what the "danger" icons are, emoji. The same annoying little faces you use on WhatsApp. So just by manipulating the URL fragment of the open web page you could inject arbitrary text and icons into a part of the native browser UI. A keen user might be suspicious of the slightly-lighter-than-normal font color, but that's definitely not something to rely on.

I worked together with Chrome developers and this issue was ultimately fixed in Chrome for Android version 43, which has been out for a while now. The way I see it, though, this was a part of a larger, more fundamental issue. The URL of the current page was allowed to wrap and was not separated clearly enough from genuine browser UI messages because of the basic usability problems of mobile devices: not enough screen estate and a requirement for an oversimplified user experience.

Certainly not easy problems to solve—I, for one, have no solutions to offer—but it pays to keep in mind that the compromises often made to work around them have implications on security as well.


No comments:

Post a Comment