The iPhone is back in the news, this time as the target of an attack. This attack seems to me like a new one on mobile phones. The Safari vulnerability that it exploits also exists in the workstation version of the program. Apple is here falling victim of their “reuse” strategy: by using the same software on workstations and phones, they have imported workstation issues.
This is quite sad, as it wipes away the advantage of their approach of not allowing third-party application downloads on the device. Either through this vulnerability or through a forthcoming one, hackers will find a way to circumvent that limit, and Apple’s strategy has helped them.
Something apparently similar has happened in the past, when a phone was attacked through a bug in the CLDC bytecode verifier. Sun has made this attack easier by a combination of two things:
- The code for the verifier is widely available, including for reverse engineering.
- Licensees are not allowed to modify this code, because it is complex.
The attacker has been able to find a bug in the code, write an exploit for it, and then unravel the entire thing on a target phone. The difference with the iPhone bug, of course, lies both in the size of the attacked code and in the virtues of public scrutiny. Very few bugs have been found in the various bytecode verifiers written by Sun, and it is quite unlikely that many exploitable bugs remain in the CLDC verifier. Overall, the strategy was good.
Now, what’s the link with Java Card? We are importing technology that was initially designed for mobile phones, not for smart cards.Just like Apple has imported Safari bugs in the iPhone, are we importing CLDC bugs in Java Card? I don’t have the answer to that, but there is hope: first, some (all?) of our origin code is now open source code, subject to public scrutiny; then, major smart card manufacturers are likely to redevelop and secure/optimize a significant part of the software, replacing the original bugs with new ones (hopefully different).
No Comments