Attacking security dialogs

Jesse Ruderman

Email: jruderman@mozilla.com

Twitter: @jruderman

I've been reading Firefox security bug reports over the years, and I've collected a list of things that can go wrong in security dialogs.

Semantic attacks

This is a class of attacks where you try to change the meaning that a security dialog has in a user's mind.

ActiveX

You might remember this dialog from the dark days of IE's dominance. The dialog includes the company's name, which is verified by a certificate authority, and the name of a program, which is whatever the site wants. Screenshot from Nick Lockard.

Onbeforeunload

Gmail

Onbeforeunload

Let's directly contradict what the fixed dialog text says. (Demo)

a.html

This is a dialog that you get if you download an app with a web browser, and then try to run it.

You might notice that the filename is shown in quotes, and filenames can't contain (straight) double quotes. But they can include single quotes...

Another problem with this dialog is the 'Open' button. It should be 'Launch' or 'Run' (or ideally 'Install').

a.html'' is safe to open. ''a.html

Sorry, Apple, for the 0-day. Try this attack on your computer. Apple Radar: 8191203.

Text-length attacks

Wrapping

The attacker just needs to own "comsecure.ly" for this to work. To make this screenshot I put "127.0.0.1 download.mac.leopard.mac.download.mac.download.apple.comsecure.ly" in my /etc/hosts file, but someone who owned "comsecure.ly" could attack people this way. Apple Radar: 8191206

Push the "Cancel" button off-screen

From Bug 214721

Push the "Install" button partially off-screen

More text-length attacks

By "key text" i mean text that's crucial to the user's security decision. Maybe it's a filename extension or a domain name.

I ♥ unicode

Right-to-left mark

Screenshot from bug 479652 in Firefox's bug database.

Right-to-left mark makes text backwards, letting you control what's at the "beginning" or "end".

Combining marks

From bug 403464. My friend Pat told me about it. Could make it look like a dialog has exploded.

Unicode Combining marks can do strange things depending on your text rendering engine. (Accents, umlauts, especially heavy metal umlauts.)

More unicode attacks

Null can cause a string to be truncated, because of differing string representations.

Homographs can be used in spoofing where the attacker wants one string to look like another.

Why do security dialogs contain untrusted text?

Want to ensure that the dialog's ability to communicate authentication and safety information cannot be impaired by a clever attacker. Test for common holes that affect dialogs that contain website-specified text.

Timing attacks

Like clickjacking, but temporal rather than spatial. See Race conditions in security dialogs for details.

Alternatives to dialogs

Mozilla has been experimenting with alternatives to dialogs. In a web browser: web sites can spam you with them; you feel like you have to make a decision right away; you can't close the tab to ignore it; you lose the sense of "place" that comes from the tab and address bar. You don't know what will happen if you deny.

iOS geolocation dialog

Information bars

Screenshot from Chrome 19 (dev) on Lion.

Info bars are in the "deny, but let the user undo the denial" camp. Info bars let you ignore the request as you read the page or close the tab. They have the advantage of not covering the page.

The API has to be async for this UI to work!

Doorhanger notifications

Screenshot from Firefox 13 (nightly) on Lion.

For some reason Mozilla has been moving from information bars to doorhangers. I think the idea is that it's going to be visually attached to the site identity button, so it's clear that you should consider it as being from the site, and you know how to get it back if you deny it. But it's less obvious that you can ignore the request; it kinda looks modal. And it's harder to just ignore because it covers part of the web site.

User-controlled API

Sometimes, you can make the security decision part of a workflow. Instead of the site asking permission to do something, the UI allows the user to do it. Another example: file pickers as a sandbox exception.

Don't provide APIs to request permission for something the user could do on their own, such as bookmarking the page. Another example: maybe we don't need onbeforeunload warnings now that we have AJAX and localStorage and undo-close-tab. I filed bug 578828 for removing onbeforeunload support.

End