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.
Or First Post (Sent from iPhone)
To offset political mods, replace Flamebait with Insightful.
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.
so true! at least put security at the method call level, not in the code-body! A user of an API should NOT be capable of even running if the user does not have permission!
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
This same poster did the same link earlier in the comments and it was reported as Goatse. Please mod parent down.
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
Your database is likely "remote" compared to the application. That is, the database is only accessible through a remote protocol, so that, unless the DB has security issues, the application AND the user can NOT do anything to the data store that they shouldn't. I see a few replies like yours... and that is the problem. If a user shouldn't be able to delete records from the "Whatever" table, accessing the database outside of the application should yield no more rights than through the application. Alike, if a user shouldn't be able to manipulate file X, then you need to implement security on the OS/Filesystem level, detached from the application. Logic in the application level can ALWAYS be circumvented, if even just with a hex editor.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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.
You are presuming that they are blunders rather than something more sinister. This may be a correct presumption, but should not be presumed so. The actual fact is, we don't know why they are doing this. If it's a mistake, someone else will take advantage of it, if it's intentional, they will, perhaps by selling the information, perhaps more directly.
So the reason is less important than the fact. But it's not unimportant, so it shouldn't be presumed. While there's insufficient information it should remain undecided.
That said, yes, there are reasons why FOSS is generally more secure. One of them is the expectation of errors being revealed. We all want to avoid embarrassment. Closed source software doesn't usually need to worry about that.
Unfortunately, this sounds like basic flaws in simple designs. Either the products are incredibly shoddy (possible when everything is being done as fast as possible as cheaply as possible), or the companies intend to take advantage of the errors which were not expected to be made public. Perhaps one of the law suits that have been launched over Carrier IQ will provide information to decide which.
I think we've pushed this "anyone can grow up to be president" thing too far.
They exist (though they're extremely immature at the Android end of the spectrum), but they're breathtakingly expensive. I'm not allowed to cite specific products or prices, but we're talking "annual licensing fees comparable to the salary of a full-time human employee for 3-6 months" expensive.
The static analyser in clang is free and would catch several of the things that people who R'd TFA say were mentioned.
I am TheRaven on Soylent News
If you read the paper you would find that *Google* phones also suffered from the problem, albeit to the least degree. Both the Nexus One and Nexus S did not effectively protect the DELETE_PACKAGES permission. That isn't exactly insignificant. Now, the likelihood of a google fixing it is rather higher than Samsung or HTC who ignored the researchers reports prior to release of the paper, but it isn't *just* a carrier issue.
Well maybe you need to read more closely too -- Those two phones allowed DELETE_PACKAGES to be called on a hard-coded string related to the pico TTS component. Basically if you used this method, you would uninstall part of a text to speech engine. This is not exactly critical. The carrier leaks potentially considerably worse though.