The special feature of these "pseudo USSD" codes on Android is that you don't have to press the call button. Simply typing the digits is enough. Note I have no idea if this particular attack actually works.
This predates Android by years. Special "phone number" codes have been used to control firmware since the very first compute went into a phone. The reason is fairly clear: in the early devices, dialing a number was the only UI metaphor available. USSD itself is actually a standard, such as it is: http://en.wikipedia.org/wiki/Unstructured_Supplementary_Serv...
Now, of course, it's just a bit of legacy nonsense that gets left enabled simply because it's part of an existing workflow and serves mostly as a hidden gotcha for people doing security analysis.
In this case, the USSD is not the bug. The fact that it can be triggered from HTML and cause a factory reset without user interaction is the bug. At least with older phones, after entry, it was necessary to hit dial before any effect was taken.
That's true, but sort of missing my point. Security bugs are very rarely "security bugs" in isolation. They're far more often unexpected interactions between subsystems. Here, the expectation of the browser is that it can fire a "phone number" Intent securely, because the dialer app will handle it. But the phone number intent also happens to hook to the USSD layer. It's not USSD's "fault", as the check needs to be in the browser according to the architecture. But USSD remains a booby trap because it's an unexpected legacy feature with surprising security behavior.
I don't think it's "android feautre", I've seen this on a few non-smart phones in the past. I don't know which one though as I owned few of them over the years.
