Slashdot Mirror
Researchers Find Big Leaks In Pre-installed Android Apps
An anonymous reader sends this quote from an article at Ars Technica:
"Researchers at North Carolina State University have uncovered a variety of vulnerabilities in the standard configurations of popular Android smartphones from Motorola, HTC, and Samsung, finding that they don't properly protect privileged permissions from untrusted applications (PDF). In a paper just published by researchers Michael Grace, Yajin Zhou, Zhi Wang, and Xuxian Jiang, the four outlined how the vulnerabilities could be used by an untrusted application to send SMS messages, record conversations, or even wipe all user data from the handset without needing the user's permission. The researchers evaluated the security of eight phones: the HTC Legend, EVO 4G, and Wildfire S; the Motorola Droid and Droid X; the Samsung Epic 4G; and the Google Nexus One and Nexus S. While the reference implementations of Android used on Google's handsets had relatively minor security issues, the researchers were 'surprised to find out these stock phone images [on the devices tested] do not properly enforce [Android's] permission-based security model.' The team shared the results with Google and handset vendors, and have received confirmation of the vulnerabilities from Google and Motorola. However, the researchers have 'experienced major difficulties' in trying to report issues to HTC and Samsung."
What does it say when I trust a bunch of random coders on the internet to give me a better performing, more secure, and overall more pleasing experience with my smartphone than the company that created it.
The lack of control the carriers have over iOS is just one of the reasons I prefer it over Android. They wanted to pre-install a bunch of junk on the iPhone, and Apple wouldn't have it. The difficulty reporting these vulnerabilities to HTC and Samsung is not surprising.
You say this, like something complex is doomed to be incomprehensible to do correctly. Simple fact of the matter is, these silly folks are still using strlen(...) and ridiculously bad coding practices, known for decades, all to come in under deadlines. I see WAY too often a multi-tier database application, where security is implemented by constantly querying what rights the user has from a "Users" table. They implement security with a bunch of 'if/switch' statements and claim "it's the nature of complex software!" when a security vulnerability is found, rather than putting security on the database.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
But you CAN root your phone, which means that these massive security flaws are actually a FEATURE of Android phones, because it will inspire everyone to root their android phone too!
Duh!
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I hope all of the people thinking it would be very cool and convenient to vote via smart phones (or the internet, or the telephone, or the mail system) will notice that smart phones might not yet be perfect.
Voting is a classic example of a situation where the requirements cry out for appropriate technology.
The requirements are unique: you must not be able to prove how you voted, you must not be able to sell your vote or be coerced by anyone, you should be able to have complete confidence that your vote was counted properly along with everyone else's.
The technology that is required is completely straightforward -- people have to go to protected locations, create physically countable and non-traceable artifacts that represent their uncoerced opinions, deposit these artifacts into a locked box at the location, and know that the contents of the locked box are properly reflected in the results.
The best way to accomplish the last step is to count the contents in public before the contents are moved, and to generate and digitally sign images of the artifacts so that anyone who wants to confirm your count is an accurate representation of the contents is able to do that.
All attempts to modernize voting for convenience's sake are misguided. All opinions that making a simple approach more complex to speed up the distribution of results are misguided. Something that is convenient but cannot be checked is not appropriate for voting. And any time a computer scientist tells you how secure something is, introduce them to real people and the way they protect their passwords.
Yea, sure bugs exist. But when you force this software on your customers, and restrict their ability to remove the software, you better make damn sure that software's secure.
Nope. This complex software (Android) has a surprisingly good security model. Carriers are installing software which ignores permissions, is not removable by the user, and creates new, serious security issues. The carriers are being evil and/or incompetent.
No no and no. Open source is not by definition vulnerable. Also, if you bother to read the title, let alone RTFA, you'd notice it is the handset manufacturer that is making the security blunders. The reference implementation (the open source stuff) "had relatively minor security issues".
Open source, assuming you have enough (competent) people working on it, is MORE secure than closed source.
In short, it appears you have some rather backwards pre-conceived notions about open source, and apparently you also have a reading comprehension problem.
AccountKiller
No problem. Just repeat your findings into one of their phones: they'll literally get the message via CarrierIQ.
You say this, like something complex is doomed to be incomprehensible to do correctly. Simple fact of the matter is, these silly folks are still using strlen(...) and ridiculously bad coding practices, known for decades, all to come in under deadlines.
I see WAY too often a multi-tier database application, where security is implemented by constantly querying what rights the user has from a "Users" table. They implement security with a bunch of 'if/switch' statements and claim "it's the nature of complex software!" when a security vulnerability is found, rather than putting security on the database.
Uh, what other way is there to implement a rights check?
Whether you get your data once or a hundred times, or whether you do a specific check or rely on the OS do it, it doesn't matter - it's still a table of users + rights, and a bunch of conditional statements the cpu plows through. You may argue that it's more error prone if you're writing a query and an if statement every time a check is needed, rather than using an API or relying on the OS to automatically call its own APIs. But you can't say it's less secure until you actually have an incident where there was an error that would have been prevented by calling the API instead of doing an ad-hoc query + if.
More likely to be insecure != insecure != less secure.
} else {
... user equals root.
}
The real Sig captains the Northwestern. This one captains
he tried using "Frosty piss" with Siri, but it gave him directions to closest outdoor bathroom
rewriting history since 2109
Wait, what now? So when it's about Android vulnerabilities it's "Faceplam. This just in: complex software has security vulnerabilities." and when it's about Windows vulnerabilities, Gates should get a death sentence and we should bomb half the planet to kill every human being has ever even touched Windows?
How then do you prevent the user from circumventing the application and using their db permissions to misbehave directly if the user should only be able to do certain things in certain situations? To say blanketly that the only correct approach to security is to implement it at the db level is naive as there are many situations where it is not desirable that the user have any permission to the DB other than through the application. It would be nice if it was possible to have a combined security that would only allow the user to have permission while going through the application, but that is also notoriously difficult (if not impossible) to implement in many situations or on certain platforms.
AJ Henderson
The real problem with android, is that handset makers release closed source binary drivers.
This creates a powerful barrier to entry against rom hackers like the cyanogen team.
Personally, I would like to see google smack some bitches by demanding either open source drivers only, or supplying feature complete whitepapers for all devices released with closed drivers intended for the android platform.
This would create a permanent hole in the current software lockdowns carriers and handset makers use.
My own phone, a samsung sidekick 4g, is basically a galaxy series device inside, but is not supported by cyanogen because of binary drivers issues, and a not fully documented cpu variant. I would very much like to ditch the stock rom, and not have to rely on cooked roms based on it, and finally get something newer than froyo with a facelift.
Requiring open drivers or feature complete white papers would fix that.
If you bothered to read the summary, the vulnerabilities lie in how the manufacturers implemented Android. To use an analogy if Dell made PCs that had a vulnerability because of the sound drivers they implemented, the fault lies with Dell. Where we give MS grief is Windows vulnerabilities affect versions of Windows regardless of the OEM that installed it.
Well, there's spam egg sausage and spam, that's not got much spam in it.