Continuing this recent theme of Android specific blog posts, I'd like to point out the remarkable repeat of history we have going on here.
Consider Apple and their "market creation" and "market leader" position they've achieved with the iPhone. Consider its key attributes: a closed system environment in every respect: closed operating system, a tightly controlled 3rd party application solution set, strict limitations on what software is allowed on the devices, and a supporting Apple proprietary media solution (iTunes).
On the scene arrives Android, an open operating platform available to all. And quickly a new business ecology is born, consisting of a myriad of companies building Android/ARM based devices to rival Apple's, all similar but all unique as well.
Does any of this sound familiar? I hope at least a few readers are old enough to remember Apple's position in "personal computing" in the early 1980's with the Apple II (and later MacIntosh) computer. They were "dominant", with their closed proprietary technology. Along came IBM with an open component approach, with all the critical components (DOS, Intel x86 microprocessors, and boot loaders, backplane and I/O specifications), generally available to all comers. I remember the full page "welcome" add put out by Apple, welcoming IBM to the party, and of course the "once only" Super Bowl ad announcing the Mac a few years later.
So what happened back then? We all know the story: the IBM PC "clone" business got rocking, and soon Apple's share in the market dropped to less than 20%. Open, clone-able, with lots of choice and variety from a multitude of vendors won out handily over single vendor, closed, more expensive and arguably "better".
The story is repeating with the iPhone and Android, and in my opinion, the story will continue to repeat. In three years, Apple smart phone share is likely to be down to a fraction of their current leadership share, and you will see massive innovation, variety and choice in the Android based product field. Apple's closed "complete ecosystem" solution will be better...and still won't win.
A side note to all of this is the question of where is Microsoft? Here we have what I believe is a fundamental shift in the computing paradigm for the masses, from personal computers to "intimate computers", computers that stay yet closer at all times to your body than those big and bulky "personal" computers. Where is Microsoft in this transition? Answer: nowhere in sight, at least thus far. The Windows environment has failed to be successful in the multiple attempts to adapt it to the smart phone form factor. The Kin product was a complete disaster and potentially reflective of a real inability to innovate successfully inside Microsoft. Apparently they will be making a fresh try soon with a "Window 7 phone"; it will be fascinating to see if they can recover and establish a serious market position.
In the meantime, the Apple vs. Android wars heat up. Apple yesterday announced a loosening of restrictions on iPhone developers, and everyone thinks this change is a function of competitive pressure from Android, and I'd have to agree. Competition is fundamental to successful capitalism and generally promoting market openness and freedom, and while I am a happy iPhone user, I like to see competition, choice and a lessening of market controlling restrictions.
To sum it up, if I was a betting man, I'd put my personal bet on Android to be the winner here. History tells us it's the likely outcome --- unless Apple will challenge that outcome by signficiantly opening up their walled garden.
Friday, September 10, 2010
Tuesday, September 7, 2010
Android Application Security
Android based devices are exploding onto our consumer products scene. By my recent count at the wikipedia list of Android devices (http://en.wikipedia.org/wiki/List_of_Android_devices), there are 97 devices shipping today, and another 57 in the delivery pipeline.
On the volume side, Android devices are also showing rampaging growth. Gartner numbers show Android smart phones at 1.8% market share in Q209, rising to an astounding 17.2% share in Q210. While I don't have "smart devices (not phones)" figures, I'd expect even larger percentages for Android. (Who are the big losers of smart phone share you wonder? No surprises there: Windows Mobile and Symbian.).
Yet the Android model is fundamentally suspect at the level of 3rd party applications. Why? Simple: the bulk of these applications are from "boutique" developers or development shops, and there is absolutely no vetting of what exactly these applications do. The potential for malware in these applications is enormous.
Android does have a mechanism that requires applications "request" capabilities at installation time. However, it appears few pay much attention to that. A few million downloads of wallpaper applications that requested sufficient capabilities to send phone specific information (SIM ID, phone #'s, etc.) to a server in China certainly proved that point (why would you grant your wallpaper application internet access? Because it asks for it and you want the wallpaper, so..."yes" you click!). A security researcher, Jon Oberheide, demonstrated the potentially malicious application "Rootstrap", which bootstrapped a rootkit on an Android device. The app, (a preview of the popular movie Twilight Eclipse) routinely polled a server to see if new Android exploit code was available, and if so would download it into the application and execute it. About 200 people installed this app, and while in this case the compromised app didn't inject malware, it's a sober reminder of how you really have no clue what you are getting when dealing with Android applications.
Is the iPhone model better? From a security perspective, absolutely. Apple is doing something with apps to vet them. What exactly they do in this vetting process they don't share (and I like many others would like them to be much more transparent about this), but personally I'm reasonably comfortable loading an iPhone app onto my phone, but would hesitate long and hard before loading any application written by any unknown publisher onto my Android device.
Don't get me wrong, I do like the broader openness that Android devices offer. After all, it's my device is it not? I should have the right to load any software I want, in my opinion. At the same time, the marketplace needs to provide me with options for ensuring or identifying problems with the security of my choices. Those options don't exist today.
This leads different parties involved with the Android device phenomena to different (sometimes overlapped) sets of requirements.
First, for the consumer, there's an enormous need for Android application vetting, some high quality "seal of goodness" that is arrived at through a reasonably thorough review of the actual code in the app and what it is doing.
For the enterprise IT professional, there's a need for the same vetting service, and of course some device management services. Corporate phones should not be allowed to be loaded with arbitrary applications; all apps should be required to come from a secure enterprise location that holds only vetted (and dare I say business appropriate?) applications, or alternatively, a vetting service can offer a means for particular enterprise phones to only download applications marked as appropriate by that same enterprise's IT organization.
For the application developer, whether a small shop or an enterprise, there is another critical need. While Android applications are signed, they are self-signed. It is not difficult to take (as an example) a well known bank's application, insert into it high value malware, re-sign it, and publish it in way that gives an illusion that it is still from or works with the original bank. Applications need protection from this kind of malware insertion. Additionally there is the usual piracy problem. Recently Google initiated an attempted solution to this, with a licensing service. However, that led to immediately demonstrated trivial cracks allowing applications to run without licensing. In response, Google has said "oh, you need to obfuscate your application code". Why, thank you Google! What have I been prattling on about in this blog for the last year? Guard your application software folks, because if you don't, others will open it and have a field day stealing and modifying it to serve their own economic agendas.
Did I mention that Arxan is announcing support for guarding of native code in Android applications yet? Yes indeed: watch for our announcement this week.
On the volume side, Android devices are also showing rampaging growth. Gartner numbers show Android smart phones at 1.8% market share in Q209, rising to an astounding 17.2% share in Q210. While I don't have "smart devices (not phones)" figures, I'd expect even larger percentages for Android. (Who are the big losers of smart phone share you wonder? No surprises there: Windows Mobile and Symbian.).
Yet the Android model is fundamentally suspect at the level of 3rd party applications. Why? Simple: the bulk of these applications are from "boutique" developers or development shops, and there is absolutely no vetting of what exactly these applications do. The potential for malware in these applications is enormous.
Android does have a mechanism that requires applications "request" capabilities at installation time. However, it appears few pay much attention to that. A few million downloads of wallpaper applications that requested sufficient capabilities to send phone specific information (SIM ID, phone #'s, etc.) to a server in China certainly proved that point (why would you grant your wallpaper application internet access? Because it asks for it and you want the wallpaper, so..."yes" you click!). A security researcher, Jon Oberheide, demonstrated the potentially malicious application "Rootstrap", which bootstrapped a rootkit on an Android device. The app, (a preview of the popular movie Twilight Eclipse) routinely polled a server to see if new Android exploit code was available, and if so would download it into the application and execute it. About 200 people installed this app, and while in this case the compromised app didn't inject malware, it's a sober reminder of how you really have no clue what you are getting when dealing with Android applications.
Is the iPhone model better? From a security perspective, absolutely. Apple is doing something with apps to vet them. What exactly they do in this vetting process they don't share (and I like many others would like them to be much more transparent about this), but personally I'm reasonably comfortable loading an iPhone app onto my phone, but would hesitate long and hard before loading any application written by any unknown publisher onto my Android device.
Don't get me wrong, I do like the broader openness that Android devices offer. After all, it's my device is it not? I should have the right to load any software I want, in my opinion. At the same time, the marketplace needs to provide me with options for ensuring or identifying problems with the security of my choices. Those options don't exist today.
This leads different parties involved with the Android device phenomena to different (sometimes overlapped) sets of requirements.
First, for the consumer, there's an enormous need for Android application vetting, some high quality "seal of goodness" that is arrived at through a reasonably thorough review of the actual code in the app and what it is doing.
For the enterprise IT professional, there's a need for the same vetting service, and of course some device management services. Corporate phones should not be allowed to be loaded with arbitrary applications; all apps should be required to come from a secure enterprise location that holds only vetted (and dare I say business appropriate?) applications, or alternatively, a vetting service can offer a means for particular enterprise phones to only download applications marked as appropriate by that same enterprise's IT organization.
For the application developer, whether a small shop or an enterprise, there is another critical need. While Android applications are signed, they are self-signed. It is not difficult to take (as an example) a well known bank's application, insert into it high value malware, re-sign it, and publish it in way that gives an illusion that it is still from or works with the original bank. Applications need protection from this kind of malware insertion. Additionally there is the usual piracy problem. Recently Google initiated an attempted solution to this, with a licensing service. However, that led to immediately demonstrated trivial cracks allowing applications to run without licensing. In response, Google has said "oh, you need to obfuscate your application code". Why, thank you Google! What have I been prattling on about in this blog for the last year? Guard your application software folks, because if you don't, others will open it and have a field day stealing and modifying it to serve their own economic agendas.
Did I mention that Arxan is announcing support for guarding of native code in Android applications yet? Yes indeed: watch for our announcement this week.
Friday, August 27, 2010
DLL Hijacking Redux
Someone once suggested there is nothing new under the sun, and that's certainly true with this week's spate of reports about DLL hijacking attacks in Windows.
This is a well known vulnerability dating back many years. New reports that that specific Microsoft applications fall prey to this vulnerability are not at all surprising (http://tinyurl.com/33btjkh).
Microsoft is quoted by Computerworld (http://tinyurl.com/23ag8kb), saying:
"We're not talking about a vulnerability in a Microsoft product," said Christopher Budd, a senior communications manager with the company's MSRC, or Microsoft Security Response Center. "This is an attack vector that tricks an application into loading an untrusted library."
Assessing this statement requires a brief review of the facts. First, this is a vulnerability driven by the fact that Windows will search in all kinds of places to find a DLL that your application requests to be loaded, if you application is so "unsecure" as to identify that DLL only by file name instead of a fully specified pathname.
Why would applications fail to use a fully specified pathname? One good reason is compatibility: Microsoft DLL's are not consistently in the same location across different versions of Windows! Therefore software striving for compatibility needs to allow Windows to search for the DLL, or search itself. A second reason is simply because Windows allows it and thereby "it's easier".
Windows first looks for the DLL by name in the current process's current ("working") directory. That's where an attacker can easily load their own replacement DLL under the same DLL name (through a wide variety of means, none legitimate but all relatively easy to perpetrate), if (as is usually the case) the current directory is not where the named DLL resides. The next time the application runs, viola, they have their own software now running on the computer. What can it do? Literally, just about anything, including quickly load other more subtle and pernicious bot-ware, key loggers, system scanners, etcetera.
Can applications operate in a manner to avoid the vulnerability? Yes, they can, but doing so is more complicated for the application developer. The key is to always load a specific DLL in a specific directory using a fully specified pathname. This in turn can create its own application compatibility issues, as any given path name to a system DLL is not guaranteed to be the same from Windows version to version! This is the true heart of the design issue, because any attempt to deal with this multiplicity of DLL locations across Windows versions in a single version of an application requires the application perform a "search" for the DLL across different directories...which is exactly what Windows does automatically for you and which opens up the application to a replacement DLL attack!
We here at Arxan are looking at this problem in an orthogonal manner, by identifying opportunities to validate that the proper DLL was loaded, regardless of its originating location. Those are the kinds of application internal security features we are quite good at. Note the elegance of this kind of solution: it doesn't require any application source code changes (because our technology inserts such checks directly into the binary application code), it creates no new dependencies on Windows specifics such as specific DLL locations in this or that version of Windows, and it is a security solution that migrates with the application itself.
To end with another ancient aphorism, if you want a job done, best to do it yourself. If you want your applications secure, don’t trust in the operating system to provide that security: secure your applications yourself!
This is a well known vulnerability dating back many years. New reports that that specific Microsoft applications fall prey to this vulnerability are not at all surprising (http://tinyurl.com/33btjkh).
Microsoft is quoted by Computerworld (http://tinyurl.com/23ag8kb), saying:
"We're not talking about a vulnerability in a Microsoft product," said Christopher Budd, a senior communications manager with the company's MSRC, or Microsoft Security Response Center. "This is an attack vector that tricks an application into loading an untrusted library."
Assessing this statement requires a brief review of the facts. First, this is a vulnerability driven by the fact that Windows will search in all kinds of places to find a DLL that your application requests to be loaded, if you application is so "unsecure" as to identify that DLL only by file name instead of a fully specified pathname.
Why would applications fail to use a fully specified pathname? One good reason is compatibility: Microsoft DLL's are not consistently in the same location across different versions of Windows! Therefore software striving for compatibility needs to allow Windows to search for the DLL, or search itself. A second reason is simply because Windows allows it and thereby "it's easier".
Windows first looks for the DLL by name in the current process's current ("working") directory. That's where an attacker can easily load their own replacement DLL under the same DLL name (through a wide variety of means, none legitimate but all relatively easy to perpetrate), if (as is usually the case) the current directory is not where the named DLL resides. The next time the application runs, viola, they have their own software now running on the computer. What can it do? Literally, just about anything, including quickly load other more subtle and pernicious bot-ware, key loggers, system scanners, etcetera.
Can applications operate in a manner to avoid the vulnerability? Yes, they can, but doing so is more complicated for the application developer. The key is to always load a specific DLL in a specific directory using a fully specified pathname. This in turn can create its own application compatibility issues, as any given path name to a system DLL is not guaranteed to be the same from Windows version to version! This is the true heart of the design issue, because any attempt to deal with this multiplicity of DLL locations across Windows versions in a single version of an application requires the application perform a "search" for the DLL across different directories...which is exactly what Windows does automatically for you and which opens up the application to a replacement DLL attack!
We here at Arxan are looking at this problem in an orthogonal manner, by identifying opportunities to validate that the proper DLL was loaded, regardless of its originating location. Those are the kinds of application internal security features we are quite good at. Note the elegance of this kind of solution: it doesn't require any application source code changes (because our technology inserts such checks directly into the binary application code), it creates no new dependencies on Windows specifics such as specific DLL locations in this or that version of Windows, and it is a security solution that migrates with the application itself.
To end with another ancient aphorism, if you want a job done, best to do it yourself. If you want your applications secure, don’t trust in the operating system to provide that security: secure your applications yourself!
Friday, August 20, 2010
Smart Phones: The Fifth Wave of Computing!
Two recent analyst reports detail the proliferation of smartphone apps. ABI Research predicts that mobile application downloads from iOS and Android will account for 78% of all application downloads in 2010, with iOS (the iPhone's operating system) taking the lion's share of 52% of all applications. Meanwhile iSuppli predicts Android will be used in 75 million smartphones by 2012, up from 5 million in 2009. Meanwhile, iOS usage will amount to 62 million in 2012, up from 25 million in 2009. Sales of these multi-function hand-held internet connected computers are expected to pass up sales of traditional PC's and laptops well before the middle of this new decade.
Overall, I believe this represents a titanic shift in the computing industry. If we step back far enough we can see perhaps four massive waves in the evolution of computing: first, the custom/boutique computing period of 1940's and 1950's, then the mainframe period of the 1960's through 1970's, then the minicomputer period from the 1970's through the 1990's, and the PC period from the early 1980's to the 2010's. The fifth wave is upon us, and it is the "smartphone" period.
Note how with each wave, old winners faded away, and new winners emerged. Nowhere is this more stark today than the fading glory of Microsoft, huge winner in the PC wave...with virtually no technology or product position in the heart of the smartphone wave.
In this new wave, the iPhone is the front runner, and Android-based smartphones are gaining in what appears to be a two-horse race, as the overall smartphone market is poised for explosive growth. This is great news for the smartphone ecosystem, while at the same perhaps a "deer in the headlight" moment for enterprise security teams.
Today's smartphones continue to expand in functionality, driven by huge numbers of innovative applications and generally better performance as a computing device. The iPhone and Android-based phone is rapidly becoming a serious alternative as a general personal computing device offering unique value in terms of personal mobility.
This is leading to sticky issues for enterprise security teams. What applications are okay to download? Will any applications used for personal purposes create any security issues (i.e. malware) with applications to be used at work? Can third party "business" applications be generally trusted? What are the additional costs to add smartphones to the already broad mix of enterprise IT managed devices? Are the appropriate security policies and underlying practices, mechanisms and resources in place?
While no doubt a daunting task for the enterprise security teams, this is yet another reason why widely used data protection methods aimed at "defending the perimeter," are not enough in today's distributed computing world. Today, companies need to adopt new strategies aimed at integrating security into the software and application themselves. Given today's distributed enterprise computing model, a modern enterprise literally has no set network perimeter to defend. This was true with the laptop and home PC being used routinely as a corporate computing devices. But now with the smart phone filling the same role, the distributed computing nature of the modern enterprise reaches it ultimate manifestation: corporate computing is happening everywhere there are employees, everywhere they go, all the time.
Obviously the security industry must roll up its sleeves and expand the notion of enterprise security. In this process, the old models of "centralized everything" probably won't work. Individuals must broaden their awareness and their personal practices, because these are "personally managed" devices. Application providors must consider the risks and take appropriate actions to protect their applications from cloning and trojan insertion. Lastly, device and the system software providers must continue to enhance and refine the security attributes, features and functions of the devices themselves.
-------------------
Late breaking news: Intel, with a growing new focus on mobile computing, acquires McAfee, and the talk is all about...traditional PC anti-virus you say? No! Not a word! The talk is all about the need for Intel to get a position in mobile/wireless computing security. Just another indication that the fifth wave of computing is upon us.
Overall, I believe this represents a titanic shift in the computing industry. If we step back far enough we can see perhaps four massive waves in the evolution of computing: first, the custom/boutique computing period of 1940's and 1950's, then the mainframe period of the 1960's through 1970's, then the minicomputer period from the 1970's through the 1990's, and the PC period from the early 1980's to the 2010's. The fifth wave is upon us, and it is the "smartphone" period.
Note how with each wave, old winners faded away, and new winners emerged. Nowhere is this more stark today than the fading glory of Microsoft, huge winner in the PC wave...with virtually no technology or product position in the heart of the smartphone wave.
In this new wave, the iPhone is the front runner, and Android-based smartphones are gaining in what appears to be a two-horse race, as the overall smartphone market is poised for explosive growth. This is great news for the smartphone ecosystem, while at the same perhaps a "deer in the headlight" moment for enterprise security teams.
Today's smartphones continue to expand in functionality, driven by huge numbers of innovative applications and generally better performance as a computing device. The iPhone and Android-based phone is rapidly becoming a serious alternative as a general personal computing device offering unique value in terms of personal mobility.
This is leading to sticky issues for enterprise security teams. What applications are okay to download? Will any applications used for personal purposes create any security issues (i.e. malware) with applications to be used at work? Can third party "business" applications be generally trusted? What are the additional costs to add smartphones to the already broad mix of enterprise IT managed devices? Are the appropriate security policies and underlying practices, mechanisms and resources in place?
While no doubt a daunting task for the enterprise security teams, this is yet another reason why widely used data protection methods aimed at "defending the perimeter," are not enough in today's distributed computing world. Today, companies need to adopt new strategies aimed at integrating security into the software and application themselves. Given today's distributed enterprise computing model, a modern enterprise literally has no set network perimeter to defend. This was true with the laptop and home PC being used routinely as a corporate computing devices. But now with the smart phone filling the same role, the distributed computing nature of the modern enterprise reaches it ultimate manifestation: corporate computing is happening everywhere there are employees, everywhere they go, all the time.
Obviously the security industry must roll up its sleeves and expand the notion of enterprise security. In this process, the old models of "centralized everything" probably won't work. Individuals must broaden their awareness and their personal practices, because these are "personally managed" devices. Application providors must consider the risks and take appropriate actions to protect their applications from cloning and trojan insertion. Lastly, device and the system software providers must continue to enhance and refine the security attributes, features and functions of the devices themselves.
-------------------
Late breaking news: Intel, with a growing new focus on mobile computing, acquires McAfee, and the talk is all about...traditional PC anti-virus you say? No! Not a word! The talk is all about the need for Intel to get a position in mobile/wireless computing security. Just another indication that the fifth wave of computing is upon us.
Tuesday, August 3, 2010
Smart Phone Privacy?
The media is in a minor uproar over (the lack of) phone privacy:
http://www.zdnet.com/blog/google/apps-on-your-phone-putting-your-privacy-at-risk/2332?tag=nl.e550
The essence of the story is that (1) you don't really know or control what all those applications you are loading onto your "smart" phone really do, and (2) they do far more spying on your phone data than you realize.
If you think such hidden spyware in phone apps is uncommon, let me tell you about a presentation at last week's Black Hat conference in Las Vegas. Kevin Mahaffey and John Hering reported in their session "Application Attack: Surviving Explosive Growth in Phone Applications" on an automated methodology called "Genome" in which they have downloaded and analyzed just about all the world's free applications for both the iPhone and Android phones.
Among their many interesting results, they found an abundance of "wallpaper" applications, all from the same author, that sent back to a server in China your phone's sim serial #, your subscriber ID, your phone line # and your voice mail #. Whoops, so much for phone privacy and application security. This news is now getting general media coverage:
http://www.tgdaily.com/security-brief/50862-as-many-as-4-million-people-downloaded-data-stealing-android-app.
These researchers also found that while it appeared that about 30% of smart phone applications "steal" your phone location information, in fact the bulk of that usage is by 3rd party adware software in those applications, which want to vend to you location targeted ads. So it's not necessarily as nefarious as it may seem, though just as with Google mail giving you targeted ads based on the content of your email, all kinds of interesting questions of appropriate bounds of privacy arise.
Before we run, scream and shout about the lack of smart phone privacy, let's acknowledge that there is nothing new here under the sun. The exact same issue presents itself on our PC's. We can and do download all kinds of apps, and they can (and do) gather and lift info.
One critical difference is that on our PC's, we don't have the same privilege management systems that at least give us the chance to know of and approve of the rights the app is requesting. So one could argue Android is superior to PC's in this regard. And on the iPhone, there is at least a minimal amount of vetting, again, an improvement vs. the PC.
A key difference here is that people have more sense of "privacy" related to a phone than to a PC. We've been inured to PC virus issues so we just assume that nothing's really safe or personal on a PC. Phone calls and phone specifics are viewed as private, so all the PC issues coming to roost on smart phones creates a media uproar.
What we need to understand and accept is that the "smart phone" device you have in your pocket (or are reading this blog post with) is not a phone! It's an extraordinarily powerful internet connected computer, with all the security issues such computers come with. All of them.
Downloading an application to a computer is a fundamentally dangerous proposition, just as wheeling in a large wooden horse into their city was a bit risky for the Greeks. The situation is worsened by the fact that the application arena for smart phones is a cottage industry. We are comfortable and reasonably safe when we load a PC application from a known business entity; when we load a wallpaper application written by "jackeey wallpaper", do we have any idea what we are really getting? Clearly not.
There is a business opportunity here, and that is to provide a technology/service that vets phone applications through internal code analysis (just as the Greeks should have first taken a look inside that wooden horse!). A "Good Housekeeping Seal of Approval", perhaps structured as a separate app store front or just as an informational service.
There is a corollary problem of how do I, as a "good guy" or "good company" publishing application software, protect my application from being trojanized and republished? If you've read any of my earlier blogs you'll find plenty of material on how to effectively deal with that.
So the next time you are about to casually download that nifty new game or whizzy app that makes your phone sing and dance...think about how much you really know about the software you will be unleashing on your "private" hand held computer, and the range of possible objectives of the person who wrote and published that software.
And beware Trojan's bearing application gifts.
http://www.zdnet.com/blog/google/apps-on-your-phone-putting-your-privacy-at-risk/2332?tag=nl.e550
The essence of the story is that (1) you don't really know or control what all those applications you are loading onto your "smart" phone really do, and (2) they do far more spying on your phone data than you realize.
If you think such hidden spyware in phone apps is uncommon, let me tell you about a presentation at last week's Black Hat conference in Las Vegas. Kevin Mahaffey and John Hering reported in their session "Application Attack: Surviving Explosive Growth in Phone Applications" on an automated methodology called "Genome" in which they have downloaded and analyzed just about all the world's free applications for both the iPhone and Android phones.
Among their many interesting results, they found an abundance of "wallpaper" applications, all from the same author, that sent back to a server in China your phone's sim serial #, your subscriber ID, your phone line # and your voice mail #. Whoops, so much for phone privacy and application security. This news is now getting general media coverage:
http://www.tgdaily.com/security-brief/50862-as-many-as-4-million-people-downloaded-data-stealing-android-app.
These researchers also found that while it appeared that about 30% of smart phone applications "steal" your phone location information, in fact the bulk of that usage is by 3rd party adware software in those applications, which want to vend to you location targeted ads. So it's not necessarily as nefarious as it may seem, though just as with Google mail giving you targeted ads based on the content of your email, all kinds of interesting questions of appropriate bounds of privacy arise.
Before we run, scream and shout about the lack of smart phone privacy, let's acknowledge that there is nothing new here under the sun. The exact same issue presents itself on our PC's. We can and do download all kinds of apps, and they can (and do) gather and lift info.
One critical difference is that on our PC's, we don't have the same privilege management systems that at least give us the chance to know of and approve of the rights the app is requesting. So one could argue Android is superior to PC's in this regard. And on the iPhone, there is at least a minimal amount of vetting, again, an improvement vs. the PC.
A key difference here is that people have more sense of "privacy" related to a phone than to a PC. We've been inured to PC virus issues so we just assume that nothing's really safe or personal on a PC. Phone calls and phone specifics are viewed as private, so all the PC issues coming to roost on smart phones creates a media uproar.
What we need to understand and accept is that the "smart phone" device you have in your pocket (or are reading this blog post with) is not a phone! It's an extraordinarily powerful internet connected computer, with all the security issues such computers come with. All of them.
Downloading an application to a computer is a fundamentally dangerous proposition, just as wheeling in a large wooden horse into their city was a bit risky for the Greeks. The situation is worsened by the fact that the application arena for smart phones is a cottage industry. We are comfortable and reasonably safe when we load a PC application from a known business entity; when we load a wallpaper application written by "jackeey wallpaper", do we have any idea what we are really getting? Clearly not.
There is a business opportunity here, and that is to provide a technology/service that vets phone applications through internal code analysis (just as the Greeks should have first taken a look inside that wooden horse!). A "Good Housekeeping Seal of Approval", perhaps structured as a separate app store front or just as an informational service.
There is a corollary problem of how do I, as a "good guy" or "good company" publishing application software, protect my application from being trojanized and republished? If you've read any of my earlier blogs you'll find plenty of material on how to effectively deal with that.
So the next time you are about to casually download that nifty new game or whizzy app that makes your phone sing and dance...think about how much you really know about the software you will be unleashing on your "private" hand held computer, and the range of possible objectives of the person who wrote and published that software.
And beware Trojan's bearing application gifts.
Subscribe to:
Posts (Atom)
