I don't have a Galaxy S3 to test this, but my experience with the Galaxy S and Galaxy S2 is that for normal phone numbers, you need to specifically confirm that you want to dial the number. For the code to factory reset the phone, though, simply typing in the code is sufficient, you don't need to press dial. It might be the same here, so that only that specific USSD code can be triggered without a confirmation from the user.
Yes, this is how it works. I tested a Galaxy S2 and HTC with Chrome and the stock Browser - both spawn the dialler and pass the code which triggers automatically on the terminating '#'.
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.
It's not the end of the world though. You're browsing on your android phone and suddenly it dials an unexpected number and you can see that it starts 900XXXXXXX or 976XXXXXXX. Most people are going to hang up pretty quickly. Sure, you might be out of pocket for up to $10 (I don't actually know how much mobile carrier charge for the connection charge), but it's not the same as losing all your data.
A more common attack vector to make money on compromised accounts would be setting up a call forward to an international number and then dialing the subscribers phone number. Illegal low cost calling cards often steal service by doing this. If there was a way to also retrieve the user's phone number, I can imagine a system where you dial the calling card company, input your code and the number you want to dial.... It tells you that it's trying to connect you and that it may take a couple of minutes... It snares the next person caught out on the website, sets their call forward to the number you want to dial, then dials that subscriber for you and connects. So then it's charging the wireless subscriber for your international call, and even if they then disable the call forward on their account, until you hang up, it's still charging them for the call forward.
