Please read: Remote USSD Attack – Clarifications
The remote USSD vulnerability I detailed in my last post (and now covered widely in the tech media) is not just a Samsung problem. The same general vulnerability (executing a USSD code without user intervention from a website, or other delivery vector) affects many phones. I’ve personally verified it on an HTC One X (running HTC Sense 4.0 on Android 4.0.3) and a Motorola Defy (running Cyanogen Mod 7 on Android 2.3.5).
I’ve also heard reports of the proof of concept working on a Sony Xperia Active.
The potential impact of the issue is limited only by whatever USSD codes can be executed on a given phone. It’s not clear if all manufacturers have Factory Reset USSDs on but at least some do.
I have only been testing with the IMEI code and have no intention to test with anything more damaging, but it is possible that in some cases different USSD codes could be handled differently. So while the IMEI code may work, it’s possible that other more damaging codes would not. This is, however, very speculative and there’s no safe way to know without testing.
Regardless it is very poor design to allow a passed value to execute as if it were keyed in interactively.
Update: It would appear that the root of the problem is probably the standard Android dialer – the vulnerability was identified and patched three months ago. For this reason it’s likely to affect any phone using the standard dialer (as it existed three months ago) or a dialer based on it.
It would be fairly trivial to weaponise the vulnerability to detect phone model with browser User Agent and tailor the response to suit.
As I mentioned in my earlier post – the simplist to mitigate the risk from this issue is to install another dialer. Either setting one that exhibit the risky behaviour as default, or simply having more than one installed to force a “Complete action using..” choice.