Home > Uncategorized > Mobile Device Applications Security: Part 2

Mobile Device Applications Security: Part 2

In my last blog entry I discussed the types of mobile device applications that are available and some of their many vulnerabilities. Presenting problems without offering solutions is a bad practice, so in this blog entry I’ll discuss solutions that are available. The problem here is that the most obvious solution whenever a vulnerability in a piece of software is discovered is for the vendor of that software to create and distribute a patch, but developers of mobile device applications are almost without exception not doing this. There appears to be a sharp bifurcation concerning the view of the necessity and urgency of patching mainstream applications versus mobile computing applications. I suspect that the reason is that the latter are used almost exclusively for personal reasons, whereas the former are used proportionately more for business reasons. Additionally, there is currently not much opportunity for developers of mobile device applications to financially profit from their endeavors, and as such developers are likely to view undertaking potentially arduous tasks such as analyzing and patching vulnerabilities as a waste of their time.

The amount of security built into an application is very much proportional to the amount of effort that programmers invest in developing security routines such as user input checking routines. Most developers of conventional applications do not adequately consider security when they code—how much less, then, must mobile application developers consider security? Additionally, although OWASP security programming standards have recently started gaining considerable momentum, many of these and other standards apply more to conventional than to mobile device application programming. The big exception to this rule is Windows Mobile implementation guidelines, which include a fair share of security-related standards. An application that is found to meet these standards is awarded “Logo Certification.”

Lamentably, I can find little evidence that mobile device applications have been tested for vulnerabilities before they are shipped to Apps Stores. For example, The Apple iTunes App Store appears to focus more on weeding out potentially offensive content in applications than on anything else. The focus of BlackBerry App World seems to be on excluding applications that can cause BlackBerrys to hang or crash. Symbian’s application screening process appears to be focused more on identifying and screening out virus-infected applications than on anything else.

There is, however, a proverbial ray of light when it comes to security in mobile device applications. Microsoft has developed a security model for Windows mobile-based smartphone applications, namely that their code can be digitally signed to allow users to have assurance of the origin or authorship of each application. These applications can run in either privileged or unprivileged execution mode. The presence or absence of signed certificates for each application determines the level of access to a smartphone functions and application programming interfaces (APIs). “Privileged trust” results in full system and API access, whereas “unprivileged trust” results in limited access to both. In contrast, untrusted applications may not be installed, nor can they reach the operating system and APIs. Users can choose security policy settings that can, among other things, require applications to be digitally signed before they can run. Other settings allow untrusted applications to run with only unprivileged access. Each execution mode ( unprivileged and privileged) can require different credentials under different conditions. For example, privileged execution mode by default requires an “operator privileged certificate” for both standard- and restricted certificate-based execution.

Unfortunately, digitally-signed code has proven itself to be a weak method of countering malicious code and other threats because it is at best an indirect method of protecting against malicious code execution. Forged certificates are a constant concern, and when a dialog box asking users if they want to continue executing a program, they almost always say “yes,” no matter what. Still, by providing both standards for secure mobile device application programming and a mechanism for limiting what applications can access, Microsoft is leading the way in mobile device application security and should thus receive an “A” for effort.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.