Remote USSD Attack - Clarifications

An interesting (and potentially devestating) remote attack against at least some Samsung Android phones (including the Galaxy S3) was disclosed recently.

Update 1: Samsung have been aware of this issue for a few months and the latest firmware for Galaxy S3 (4.0.4) appears to resolve the issue.

Update 1a: While some 4.0.4 versions appear to be secure, others are vulnerable.

Update 1b: The issue has been patched in some firmware builds. It appears that all 4.1-based builds are safe, and possibly some 4.0.4 builds are also.

Update 2: Samsung is not alone in being vulnerable to this issue.

Update 3: Some apps have been created specifically to catch these URL calls: TelStop (by @colimrm) and Auto-reset Blocker

In brief it works like this:

• Phones support special dialing codes called USSDs that can display certain information or perform specific special features. Among these are common ones (*#06# to display IMEI number) and phone specific ones (including, on some phones, a factory reset code). 
• There is a URL scheme prefix called tel: which can, in theory, be used to hyperlink to phone numbers. The idea being that clicking on a tel: URL will initiate the phone's dialer to call that number.
• In some phones the dialer will automatically process the incoming number. If it's a USSD code then it will be handled exactly as if it had be keyed in manually - requiring no user intervention to execute.
• A tel: URL can be used by a hostile website as the SRC for an iframe (or potentially other resources like stylesheets or scripts I guess). It may then be loaded and acted upon with no user intervention at all.

A video demonstrating the process has been widely circulated - it also details some other vectors to deliver the tel: URL - including WAP Push SMS, QR Code and NFC. All of these processes have the same end result.
I created a small page to test the attack myself (using the non-destructive *#06# IMEI code rather than the very damaging factory reset one) and replicated the outcomes displayed in the video and documented elsewhere.

The fundamental problem here is the dialer. It is acting on the phone number it's sent exactly as it would had it been keyed in directly. If it the tel: URL can be directed to an application that does not have that behaviour then the threat can be neutralised.
Thankfully Android allows for alternate dialers to be installed. I picked a popular one from Google Play - Dialer One - and installed it. Even with out making it the default phone dialer I have prevented the threat. A tel: URL will now prompt me for the application to use.

If I select the standard dialer the same issue reoccurs, but if I select Dialer One (which does not take action on the incoming USSD code) or cancel the request entire I am protected.

It's likely that many other dialers behave in the same way, but you should test them carefully. The important thing is to avoid letting the stock dialer handle tel: URLs without direct user interaction.