Mac enthusiasts have chided Apple, Inc, for not having the marketing savvy of rival Microsoft. The implication is that the Cupertino tech powerhouse should learn from the Redmond giant when it comes to the ways in which the latter grows its market share.
I cannot argue with that; in fact I think there is probably a lot of truth to it. However, it is now clear to me that there is one thing Apple has learned to do the Microsoft way a little too well: making the default browser run with too many privileges.
According to a PC World report, researchers participating in 3Com's annual Pwn2Own competition were able to hack into both the latest iPhone and Macintosh computers using the Safari web browser as attack vector.
Although it is not initially apparent to the average user how much privilege the Mac version of Safari runs with, the iPhone version is too ubiquitous and is used in too many cases on the portable device to not be seen as a base app with tentacles in many of its functions.
It seems as if the Mac's Dashboard desktop application uses the same WebKit rendering engine that Safari uses; and therein lies the weakness the browser represents. Just as with Microsoft, Apple could not resist the temptation to sacrifice security on the altar of efficiency.
What should Apple do? I was initially tempted to suggest that they take a page from Konqueror, the browser used by the KDE project. It integrates with the UI yet appears to be quite secure. I remember being warned by it when it detected a rogue website containing a VBScript exploit that would have allowed a hacker to gain command line control of a client Windows machine.
However, I am a little cautious because Konqueror would not have been vulnerable to such an attack even if it had not been detected. I am left to wonder if it would be as resilient with an attack tailored toward a language it has a runtime for.
Either way, I must at least credit the Konqueror web browser if only because its creators seemed to have been aware of the possibility of such attacks, unlike their fellow WebKIt users over at Apple.
At the end of the day, however, it all seems to boil down to privileges. If both the web browser and the UI shell — with its almost unlimited access rights — are to use the same rendering engine for HTML/XML content, then a way needs to be devised that will grant or deny privileges based on the source of invocation.
The Snow Leopard exploit granted command line access to a hacker for the computer running Safari. The iPhone OS vulnerability, for its part, allowed access to the devices SMS contact list. Although the details of the attacks have not been fully disclosed, we can safely infer that both exploits gave unauthorized local access to a remote user by using the web rendering engine or its parent process.
Maybe the rendering engine should be rewritten in a way that checks for the credentials of the invoker. Maybe, the OS should run a separate copy for local tasks. Whatever the solution, this pivotal security barrier should never be broken.
When a third party browser, such as Firefox or Opera, is run. Obviously, the incestuous relationship between browser and OS shell is to blame. Come on, Apple, you know better than to learn from the OS family with possibly the worst security record in the history of computer operating systems.
