Android Holes Allow Secret Installation of Apps 132
CheerfulMacFanboy writes with a link to Heise Online which says "'Security researchers have demonstrated two vulnerabilities that allow attackers to install apps on Android and its vendor-specific implementations without a user's permission. During normal installation, users are at least asked to confirm whether an application is to have certain access rights. Bypassing this confirmation request reportedly allows spyware or even diallers to be installed on a smartphone.' One vulnerability was identified when a security specialist analysed HTC devices and found that the integrated web browser has the right to install further packages (used to automatically update its Flash Lite plug-in). Attackers can exploit this if they have found another browser hole. 'Android specialist Jon Oberheide demonstrated another hole which involved misusing the Account Manager to generate an authentication token for the Android Market and obtaining permission to install further apps from there. However, this initially requires a specially crafted app to be installed on the smartphone. Nothing could be easier: Oberheide released the allegedly harmless "Angry Birds Bonus Levels" app into the Android Market and, upon installation, this app downloaded and installed three further apps ("Fake Toll Fraud," "Fake Contact Stealer," and "Fake Location Tracker") without requesting the user's permission.'"
Time to move to a repository system? (Score:5, Interesting)
As mentioned before on /., Maybe Google should consider moving to a repository system. By default, Android devices should have a repository where apps are vetted, Apple App Store style. Of course, have the ability for a user to easily turn on the second repository (which would be the current Google App Store) for items not found on the "blessed"/default repo.
This has worked for OSS projects for over a decade. It should work quite well for Android.
Re:Makes popcorn (Score:3, Interesting)
Is this type of thing news? Only in the sense that it serves as a reminder to those who will listen that you have to be careful about what you do with your phone/computer/etc.
Re:Adobe @#^@#$ us over again (Score:1, Interesting)
I'm not sure that throwing a systems guru at what is effectively application software would be a prudent use of company funds. First off, going by the available feature set for Flash "developers," the code base for the Flash runtime would make Java and its standard libraries look concise. Hell, it implements two discrete native scripting environments; I'm not even getting anywhere near rendering logic.
Now you might say that in a sane world, "systems" logic (such as device access) would be entirely separate from "application" logic (rendering) — but this is Adobe, and more specifically, Flash. They didn't write the code, they acquired it (it was, until recently, Macromedia Flash, remember?). I'd wager further development happened through accretion, not top-down design, and all of this on top of a 10+ year-old code base likely running into the millions of lines in an unknown programming environment.
Add in the fact that there's likely a very strong legacy support issue in that Flash output from earlier versions is playable in later players. Again, one would hope that the bytecode parser is separate from systems logic, but there's a decent chance that somewhere along the line there has been some mingling for a compatibility issue.
None of this is to disagree with you on the crux of the issue, of course. Adobe's programmers, until recently, maintained one of the largest bodies of consumer-facing Fortran code (Photoshop!). Somehow, in a year, they replaced it all with C and managed to keep execution times similar — which doesn't sound like much, until you remember that Fortran's strength is numeric computation and these algorithms are very well known and formally studied. So yeah, probably not a manpower or skill issue, but a business issue — the average user doesn't care about security and Adobe knows this.
Re:General purose computing device (Score:2, Interesting)
I want a limited device that only do what I want and no more. The "no more" part is important to me, as it keeps the cost of ownership low.
It's called the 90-10 problem. 90% of the users only want 10% of the features. The problem is that they don't all want the same 10%. This is why modern computers have so many features that you never use - it's not because people want general purpose computers, it's because people all want different special-purpose computers.
Re:What of old versions (Score:3, Interesting)
True, but while CM has been a great solution for a while the focus of that distro has moved on to newer phone models. While CM 6.0 runs on the G1 it is VERY slow, and doesn't support apps/data on SD ext3, and official Froyo apps on SD doesn't work well for many apps.
6.1 seems to be a lot better, but I think it is only a matter of time before the G1 stops getting much attention, which then leaves a lot of more experimental mods floating around. CM was nice because it focused more on usability/stability and was less of a POC build.
It is like the 1990s all over again - developers tend to be enthusiasts who buy the latest and greatest, so they always build stuff that doesn't run well on older PCs. We've gotten away from this in the last 10 years since modern PCs (except in the area of graphics) have not really been improving much as they are no longer CPU-bound, and most developers don't own SSDs yet.
Phones, however, are on a very Moore's-law like curve which means that when you donate to your favorite phone modder you're giving him a change to get a newer fancier phone and stop supporting yours. :) Granted, that doesn't mean that the solution isn't to reward them for what they've done for us.