This site graciously hosted
by our friends at
13 February 2004
Earlier this week, UK security firm Al Digital published the results of a study (see full text at http://www.techonline.com/community/news/33420) that it performed on numerous mobile phones. According to its study, there are numerous Bluetooth-related vulnerabilities in mobile phones manufactured by Nokia and SonyEricsson. The vulnerabilities enable, under certain circumstances, a "bluesnarf" attack: an attacker with a Bluetooth enabled device (e.g., a laptop or a PDA) can read AND write to a vulnerable phone's phone book, calendar, and other internally-stored information.
To those of us that have been observing the Vulnerability Circus for some time, this does not come as much of a surprise. "Vuls" in our world are discovered on a more or less daily basis.
What is disturbing is that mobile phone manufacturers, relatively new to this process, do not yet have in place the necessary infrastructure to be able to respond to such vulnerabilities in a fully acceptable manner. But mobile phone manufacturers can no longer hide behind the shield of "we're just isolated devices running our own embedded code". The fact is that they became Internet-connected data devices when they added IRDA, Bluetooth, and other forms of data communications.
In our opinion, that changes the rules of conduct. They ought to be held to the same standards to which we hold our operating system vendors. That is, they need to develop corporate mechanisms for fixing, announcing, and distributing bug fixes to their users. Over the years we have seen the major operating system producers become increasingly responsive to fixing the problems (although many would argue that much work remains to be done). Now, we believe that it's time for mobile phone manufacturers and makers of other embedded systems to step up to the plate. Of course, it is quite possible that some of them already have something in place that we are unfamiliar with, but from our perspective as avid consumers of these technologies, they have a long way to go.
There's more to software security quality than good patches, of course. There's no substitute for well designed and written code in the first place, and developing code for these now Internet-connected devices ought to be done with more care than had been the case when mobile phones were truly isolated from the public information infrastructure. Security concerns should be built in at every stage of the development life cycle. Even still, mistakes will happen and bugs will need to be fixed.
The security quality of today's operating systems isn't much to brag about, that's for sure. But current practices do embody some good lessons that were learned at real cost. Seek out vulnerabilities in your products. Acknowledge them honestly, fix them aggressively, and--most importantly--feed the lessons learned back into the production process so that real security can be built in at the design level in future versions.
In our view, the users of this mobile technology--and that's all of us, folks--need the mobile phone manufacturers to learn, right now, from the models in place with the traditional software manufactures for fixing (and better yet, avoiding) software vulnerabilities.
Mark G. Graff
Kenneth R. van Wyk
Authors, Secure Coding
Copyright (C) 2004, Mark G. Graff and Kenneth R. van Wyk. Permission granted to reproduce and distribute in entirety with credit to authors.
Site Contents Copyright (C) 2002-2004 Mark G. Graff and Kenneth R. van Wyk. All Rights Reserved.