Linked by David Adams on Thu 24th Jun 2010 16:22 UTC, submitted by Governa
Privacy, Security, Encryption About 20 percent of third-party apps available through the Android marketplace allow third-party access to sensitive data, and can do things like make calls and send texts without the owners' knowledge, according to a recent security report from security firm SMobile Systems. There's no indication that any of the highlighted apps is malicious, but the report does underscore the inherent risks of a more open ecosystem as opposed to Apple's oppressive yet more controlled environment, with every app being vetted before availability.
Permalink for comment 431444
To read all comments associated with this story, please click here.
Why the App Store is not a revolution
by Neolander on Fri 25th Jun 2010 08:23 UTC
Neolander
Member since:
2010-03-08

Here, I'll explain in details why I think that the App store is not a revolution in security, and how things can really be improved, based on simple computer security notions.

Let's take as a basic assumption that absolute security does not exist. It's effectively true, because it would require the user to make any kind of hardware and software he uses all by itself. The best we can do is to reduce the amount of trust that the user has to put in third parties. As far as I know, these are the strategies which exist as of today :

1-Keeping the user well-informed and in control.
2-Make knowingly malicious software disappear.
3-Have experts analyzing the software and say if it can be relied upon.
4-Be cautious about what kind of software is installed, do not let anything make its way.
5-Put limitations on what software is able to do.

Now let's analyze those strategies. First from a philosophical point of view.

1, 4, and 5 are at the same time the most safe and liberal (as opposed to authoritarian) solutions. They don't require to trust an additional third-party about what is safe, the user is independent instead of being treated like a child.
2 and 3, on the other hand, are more dangerous, because you have to rely about an unknown bunch of people who pretend to know what is safe (and can be themselves authors of malicious software). For that reason, those options should not be used independently, but rather as a complement of other options that one can bypass.

Now, let's get more technical.

1/Keeping user informed
One might argue that it requires the user to have some previous knowledge of malware. However, everybody has such knowledge, to some extent, in the form of common sense. If an unknown guy comes at home and ask if he can borrow your TV set, you'll probably say "no", because you're almost sure that he will never come back. What the system manufacturer has to do is to describe, in an understandable yet precise fashion, what the application wants to do. Precision is important : an application should not ask for "access to system files", but rather for "ability to change active wi-fi connection". This requires a fine-grained underlying security permission system.
A second thing the system manufacturer can do is to make the system analyze the permission being asked, and specifically warn the user about dangerous ones. As an example "Make a phone call with prior acknowledgement from the user" is relatively safe, while "Make a phone call without prior acknowledgement" or "Access all system files" are dangerous options, which the security system should warn the user about.
A security system built around those ideas can both help an expert who wants to know if the application is safe and a non-technical user who can check, at his knowledge level, if the software is asking for reasonable things.

2/Remove known malware from user sight
This is the most obvious benefit of a central repository system. All properly maintained central repositories (from Debian's APT repos to the Android market) provide this kind of security, and it cannot work properly outside of such a system, as anyone who experienced antivirus software on Windows can acknowledge. This system has, however, a major flaw that make it insufficient alone except in technical environments : in order to work, it requires a large and representative part of the user base to keep the repository maintainers informed about what malware they have found.

3/Expert check
This one is quite interesting, because it is were being open-source can actually result in increased software security. That's because a source code can generally be fully checked for malicious behaviors in a reasonable amount of time. In a binary-based system, however, such a full check cannot be performed, and the sole advantage that an expert has over an average user is his experience (which is not necessarily worth much in a rapidly-evolving and polymorphic area like malware).
All the expert can do, when being given a binary file, is to try to run it in every single possible way and check for unwanted behaviors. However, this is insufficient. Suppose that an attacker makes malware which looks like a plane reservation application. The application checks plane availability from a distant server (which is controlled by the attacker), and allows the user to book a seat. However, if a specific available plane is registered on the server, the application suddenly goes evil. This is commonly called a backdoor.
The attacker first submits his application to the expert, with usual content on the server. The expert stress-tests the app, and notices no strange behavior, so he approves it, and people start to download and use the app. Once the app is widespread, all the attacker has to do is to put the fatal entry on the server, and BOOOM ! Millions of phones are suddenly tainted by malware.

4/Thinking before installing
This one can be very effective again phishing-like attacks ("Your phone is slow because it is tainted with malware ! Download this absolutely free software to remove it !"), but it requires prior education of the user.
Does one really require to replace a phone book ? A core component of the system like the control panel or the filesystem manager ? One shouldn't give very high permissions to an application without thinking not twice, but rather three times. If a core component of the system doesn't work, you should consider moving to another system, warning the manufacturer about its defects, or patching it yourself if you're a technical user and it's free software. Relying on several third-parties for core components of an OS is generally a bad thing, as some Linux user may acknowledge.

5/Limiting apps capabilities
This one is *extremely dangerous*. People who wrote the security system just don't know what the users will do with their computer. Moreover, computer usage varies wildly as time passes. Who are we to decide what is good for the user ?
However, this idea can find its place in a less extreme form, that is carefully choosing what an application can do without a security permission being given. As an example, consider a situation where applications have a private folder, sort of like in OSX. They can do whatever they want in said folder, but they can't do anything outside of that folder without prior acknowledgement (as an example through use of an "open file" dialog, or by getting the appropriate security permission). This way, the amount of warnings about security permissions can be reduced, and hence once one does appear, there are higher chances that the user will read it instead of just clicking "next"/"ok"/"ack"/whatever right away.

Now where does the App store fits in this model ? Most smartphone OSs use a combination of repositories and limited abilities. Android adds up an informed user. The App store chooses to add up an expert check, which, as we've seen before, certainly isn't the most effective way of managing security, except if the users are dumb or uninformed (I prefer to think that the latter option is the good one). It's not intrinsically superior, given that the security systems are properly designed and patched, it's still three security principles out of five available.

One must them ask himself if relying on experts who can do little because they have to check binary apps is worth being forced to download from this repository, which has no security benefit and is a purely jerkish move from Apple aiming at maximum incomes...

Edited 2010-06-25 08:31 UTC

Reply Score: 2