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."

Comments

facepalm

[masternerdguy]

This just in: complex software has security vulnerabilities.

Re:facepalm

[TheRealMindChild]

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.

Re:facepalm

[The Moof]

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.

Re:facepalm

[TheCouchPotatoFamine]

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!

Re:facepalm

[MozeeToby]

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.

Re:facepalm

[sexconker]

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.

Re:facepalm

[CmdrPony]

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?

Re:facepalm

[masternerdguy]

If you've read my posts you'll see I really am not a google fan.

Re:facepalm

[AJH16]

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.

Re:facepalm

[TheRealMindChild]

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.

Re:facepalm

[kelemvor4]

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?

Welcome to slashdot.

Re:facepalm

[lavacano201014]

This is why you root your phone and remove this software if--no, when it causes problems. Make sure you keep a backup of it though - you'll need to restore it and unroot if for some reason you need to send it in under warranty.

Re:facepalm

[sexconker]

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.

You don't know anything about my database.

The only users my database has are the system account, and a user for each application.
All access is done through the applications. The applications have full access to their respective databases and tables, and the users of those applications are restricted in their rights by the applications. Users have no access to the database directly.
It's all web-based, so logic in the application can NOT be circumvented unless you have access to the application code. If someone has access to that, they have access to everything.

I see a few replies like yours... and that is the problem. If you talk out of your ass without understanding that shit isn't always done exactly in the myopic way you think it is, then you're going to make a fool out of yourself.

If a user shouldn't be able to do X, then all you have to do is ensure that they can't do X. It doesn't matter how you go about doing it as long as it works. Easy to maintain and easy to understand are a bonus.

Re:facepalm

[UnknowingFool]

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.

Re:facepalm

[bberens]

It's very unlikely that an application user has a 1-to-1 ratio with database users. Let's say I have an online store that sells widgets. Each application user can see their purchase history. The one database user has access to everyone's purchase history. In this condition a flaw in the application can lead to exposing someone else's purchase history. The only applications I've seen where there was a 1-to-1 ratio such that one customer was limited at the db connection layer from another person's data were not expected to scale at all.

Re:facepalm

[Anonymous Coward]

It's very unlikely that an application user has a 1-to-1 ratio with database users. Let's say I have an online store that sells widgets. Each application user can see their purchase history. The one database user has access to everyone's purchase history. In this condition a flaw in the application can lead to exposing someone else's purchase history. The only applications I've seen where there was a 1-to-1 ratio such that one customer was limited at the db connection layer from another person's data were not expected to scale at all.

Yeah. 1-to1 is the proper way to do it. The failing of most people to implement it is in itself an explanation of this story.

Re:facepalm

[thoromyr]

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.

Re:facepalm

[Anonymous Coward]

You forgot, when it's an i device, the vulnerabilities are a feature (i.e. allowing a jailbreak =P)

Re:facepalm

[Anonymous Coward]

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.

Re:facepalm

[swillden]

You say this, like something complex is doomed to be incomprehensible to do correctly.

A claim which is particularly interesting in light of the fact that the Google phones had no significant flaws (at least under this analysis). Does it really surprise anyone that all of the crapware loaded by the carriers causes problems?

Re:facepalm

[LordLucless]

Uh-huh. So for instance, on a web-app, your recommendation would be that every time a user signs up, the app creates another database-level user with specific permissions. So your app now has to have permissions to grant permissions on a database, and you could well end up with a couple of hundred thousand database users. Man am I glad you don't work with me.

Also, in the implementation of most databases, user rights are still just queried from a table. The only difference is the tables are managed, and the queries run by the database instead of the application.

Re:facepalm

[Anonymous Coward]

Not only is that my recommendation. It is obvious that the schema of such a system would work. You are arguing that technology can't provide that. What is that really saying?

Re:facepalm

[Builder]

I think the key difference is the number of us who've had to clean up after Gates and suffer the outcomes of his security.

Every time some windows botnet completely outside of my ability to control hammers on my public facing boxes and I have to divert time into dealing with or mitigating the impacts of that traffic, I look to the sky, shake my fist and scream GAAAATESSSS! All of the time I spend doing that is time that I don't spend adding real value to my customers.

How many of us that run secured equipment and platforms have been bitten by one of these phone bugs yet ?

Re:Android sucks

[secretplans]

You should have gone with "First!".

Ars Technica?

[Anonymous Coward]

How about a link to the quoted article?

Re:Ars Technica?

[NatasRevol]

Or not linking to a PDF named Woodpecker?

Cyanogenmod

[Skarecrow77]

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.

Re:Cyanogenmod

[NatasRevol]

That they stood on the shoulders of giants, and combed their hair?

Re:Cyanogenmod

[iluvcapra]

People who own and use phones have a greater incentive to make a good phone OS than people who sell and provide service to phones.

Re:Cyanogenmod

[Drew M.]

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.

We refer to that as the "Open Source" development model

Re:Cyanogenmod

[Anonymous Coward]

wtf does that even mean? what's wrong with you?

Re:Cyanogenmod

[GameboyRMH]

That was my first thought - are privacy and commercial success mutually exclusive for mobile devices? It seems that once a mobile OS is adopted by a large market the sleazebags move in to load it up with shovelware that siphons off your personal data (in the case of Android, that includes the carriers and even the manufacturers). Meanwhile the geek-oriented OSes (custom Android builds, Maemo/MeeGo, Ubuntu Mobile, etc) running open-source apps with funny names exist happily with no problems.

Re:Cyanogenmod

[Anonymous Coward]

I believe it means you have misplaced trust. You can't trust random internet coders either. Do you know who writes most malware? Yes, some is written by corporations - see Sony's root kit and this current Carrier IQ. But most is written by random coders on the internet. Me? I don't trust the company that made my phone. I don't trust random coders on the internet either.

Re:Cyanogenmod

[blair1q]

It means they can root your phone so you can install their, um, rootkit, essentially....

Re:Cyanogenmod

[clarkn0va]

You're right, and what a sad statement that is on the current state of affairs when a group of companies can treat their consumer base with something between indifference and contempt and yet continue to profit from them.

Re:Cyanogenmod

[jasno]

Look, the people who develop the phones use them too. The reality is that there just aren't that many smart, motivated, capable engineers out there. Even when you have a few alpha-engineers on a team, their time is usually spent trying to squash those hard-to-fix bugs instead of doing a thorough security analysis. They're rushing to get the damn thing to production so they can move on to the next big thing.

I've spent my career developing embedded applications and not once has anyone paid me to address security. Bugs - user experience issues, stability problems, content security, standards compliance - those get the money. No one in management values security or privacy and they won't unless security researchers and hackers make the consumer aware of it.

Re:Cyanogenmod

[jasno]

Actually - I wonder if there is a certification agency for security/privacy? I've never heard of it, but if someone like the EFF got together with a testing lab and established a logo-certification program for various classes of devices(phones, operating systems, set-top boxes, networking equipment, etc.) you'd have a way for the consumer to evaluate security and make decisions accordingly.

Re:Cyanogenmod

[swillden]

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.

Except that the phones from the company that created the OS, Google, didn't have any security issues. CM is cool, but it's less secure than a standard Google build, not more. Although it probably is more secure than Android as delivered by the carriers.

Re:Cyanogenmod

[Anonymous Coward]

I don't know.

It's not like a similar thing happens with... say... PC games. *MY SIDES*

Re:Cyanogenmod

[assertation]

Would using this software have protected a person against Carrier IQ's rootkit? I don't know anything about smart phone tech. I was actually thinking of getting one until this story broke. If I can gut the software and use something like a cyanogenmod to protect myself against privacy abuse that would be golden.

Re:Cyanogenmod

[MikeBabcock]

That you realize random coders on the internet are more likely to care about the end results of their product than a monolith like Samsung?

Where are the free source code scrubbers?

[rtp]

We need automated tools to catch obvious security errors in software much like grammer and spelling checks in Word processors.

The use of automated source code review tools should become more popular, especially as a well-linked resource from inside SourceForge and other sites that promote software development. Based on the number of security vulnerabilities so frequently found in software, there's got to be some signature-based checking that could catch the common mistakes, which could be made available by the likes of Google or others who have an interesting in raising the bar for their platforms.

Re:Where are the free source code scrubbers?

[Anonymous Coward]

> grammer

Spill cheque woks grate!

Re:Where are the free source code scrubbers?

[Miamicanes]

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.

Re:Where are the free source code scrubbers?

[TheRaven64]

The static analyser in clang is free and would catch several of the things that people who R'd TFA say were mentioned.

Re:Where are the free source code scrubbers?

[Miamicanes]

Unless something has massively changed in the very recent past, Clang doesn't analyze Java (directly). EVEN IF you somehow managed to coax gcc into outputting something Clang can analyze, it's questionable whether the output would even be relevant. At best, you'd be scanning for vulnerabilities due to bugs in Android itself (which obviously exist, but are unlikely to be easily found as low-hanging fruit). At worst, you'd be completely wasting your time looking for vulnerabilities that might hypothetically exist if it ran under Hotspot, and totally miss any real vulnerabilities that might exist due to Dalvik.

Re:Where are the free source code scrubbers?

[TheRaven64]

Who said anything about Java? The exploits in question are in C code using the NDK.

Re:Android sucks

[masternerdguy]

Or First Post (Sent from iPhone)

Carriers

[bonch]

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.

Re:Carriers

[robmv]

Not again the iOS vs Android mantra about carrier installed crap, do you want a new clean phone? buy it unlocked without carrier intervention. Expensive? need financing? Use your credit card financing services, problem solved. And this worked since the old smatphones generations, I used Nokia and Sony Ericsson phones before the Nexus One

Re:Carriers

[Ihmhi]

Sure, but what about when some sort of vulnerability is found in iOS? It's not like Apple is somehow magically invulnerable to software security issues. At least with a lot of Android phones you can do something about it without getting too much shit (if any) from your carrier.

Re:Carriers

[Anonymous Coward]

The IPhone comes with a pile of junk on it too, which you can't remove. Furthermore, Apple have admitted they've been using Carrier IQ, which was obfuscated from detection.

Finally, the iPhones are the only phones you can root by merely going to a website. Now that is utterly pathetic!

Re:Carriers

[HiThere]

IIRC Apple *installed* Carrier IQ, but it wasn't activated unless you enabled "send debugging information". Something like that. I don't have an IPhone, and I can't quite remember the precise activation mechanism.

Now of course this doesn't mean that they might not activate it in the future via some "security upgrade". That kind of behavior is what turned me off to Apple. But *currently* they appear to be using it in a reasonable manner.

Re:Carriers

[denis-The-menace]

Where does one buy such a phone that is not locked down at the onset WITH warranty?

Re:Carriers

[UnknowingFool]

iOS is not any less vulnerable than Android when it comes to security. This specific issue highlights that the vulnerabilities can occur because the manufacturer screwed up Android implementation. Apple is less likely to do so as they control the hardware and software. Also with as much profit as Apple makes, they don't have any excuses. With Android manufacturers, they might have a lack of QC due to lack of money or that they really need the revenue generated by crapware.

Re:Carriers

[UnknowingFool]

According to some posts I read, the activation was when you first set up your iPhone. The setting can be changed at any time in the phone's settings. Apple has said they will remove CarrierIQ going forward in iOS5 updates and disable it in iOS 4 updates.

Re:Carriers

[iluvcapra]

Apple is less likely to do so as they control the hardware and software.

I would agree that they have more incentive to make sure things work, and they have more liberty to make the necessary changes, but these don't always translate into better outcomes. They have so far, though.

Re:Carriers

[Anonymous Coward]

apple.com

Re:Carriers

[robmv]

You must be living in USA, the country of locked phones, but just check the Nexus line, Sony Ericcson and even Nokia

Re:Carriers

[PNutts]

It's only operational on the iPhone 4 if you opt into it. It's already been disabled on all other phones and will be removed in a later version of iOS6.

Re:Carriers

[PNutts]

Crap. In a later version of iOS5.

Re:Carriers

[PNutts]

The IPhone comes with a pile of junk on it too, which you can't remove. Furthermore, Apple have admitted they've been using Carrier IQ, which was obfuscated from detection.

Finally, the iPhones are the only phones you can root by merely going to a website. Now that is utterly pathetic!

I'm not sure why I'm bothering, but what junk are you referring to? You may not want a magnetic compass or a calculator but I wouldn't classify it as junk. Put it in a folder off your home screen and I doubt it uses more disk any song that's not innagadadavida.

The iPhone's diagnostic data is not obfuscated. It's plain text and available/viewable from the menu. It never recorded keystrokes.

True about the website and many people see that as a benefit. Downloading and running an app to root is so 1990.

Re:Carriers

[Karlt1]

Sure, but what about when some sort of vulnerability is found in iOS? It's not like Apple is somehow magically invulnerable to software security issues. At least with a lot of Android phones you can do something about it without getting too much shit (if any) from your carrier.

Every iOS device introduced after June 2010 is supported with OS updates and security fixes from Apple. Can Android users say the same?

Let's see....
Android
1. A security vulnerability is found
2. Google patches the vulnerability
3. Android makers may apply the patch to currently selling phones.
4. The carrier may push out the update for recently sold phones.

(Steps 3 and 4 are never done the day the OS patch is released.)

iOS
1. A security vulnerability is found
2. Apple patches the vulnerability
3. Apple sends out a notification to every iOS device worldwide running iOS 5.
4. Any iOS user worldwide can click on update from the device and get an update

And no, "rooting the phone and downloading a third party hacked build" is not an acceptable alternative to most users.

Re:Carriers

[Anonymous Coward]

You have been able to buy factory unlocked iPhones with full apple warranty from Apple (in the US as well as most other countries) since the iPhone 4 and outside the US since the iPhone 3 at least. You just have to be smart enough to realize that you are better off paying the full retail price for the phone and owning it without any restrictions vs paying the carrier subsidized price and then being locked into an expensive contract for 2yrs and unable to use the phone while traveling, etc without incurring HUGE roaming charges.

Re:Carriers

[scot4875]

Every iOS device introduced after June 2010 is supported with OS updates and security fixes from Apple. Can Android users say the same?

Nope. My Evo doesn't get *any* OS updates or security fixes from Apple.

--Jeremy

Re:Carriers

[Karlt1]

Sure it does. When a vulnerability is found in WebKit and Apple patches it, it get's checked into source control and eventually used by Google.....

Re:Carriers

[denis-The-menace]

I live in it little brother up north, the OTHER country of locked phones. (Our regulator is a revolving door to vendors)
I was hoping for Motorola droid razr.

Re:Carriers

[bonch]

I don't mean to imply that Apple is "magically invulnerable" to security issues. The point is that software out of their control doesn't come pre-installed on the phones at the whim of the carriers. It also puts responsibility on Apple rather than obtuse vendors like HTC or Samsung who won't respond to security issues, according to this story. Hell, most Android phones never even get an official update to their software.

At least with a lot of Android phones you can do something about it without getting too much shit (if any) from your carrier.

If you think rooting a phone is a realistic solution for the average consumer, you don't get the average consumer.

Re:Carriers

[bonch]

I didn't say iOS was any less vulnerable to Android when it comes to security; I thought I was clear that I was discussing the lack of carrier intrusion in the shipping operating system. As the story claims, HTC and Samsung aren't even responding to these security issues, and as you point out, Android manufacturers might not even have quality control measures or may be dependent on revenue from crapware, which just adds to my point.

Re:Carriers

[Anonymous Coward]

True about the website and many people see that as a benefit. Downloading and running an app to root is so 1990.

Wait, seriously, the iPhone has remote root exploit that can be accessed by any webpage?!

Quick, I want to figure out how to embed rm -rf / (or whatever the Apple version of that is) into my website, so any Apptard that visits gets a friendly trip to the nearest "Genius" Bar!

Re:Carriers

[SignOfZeta]

True about the website and many people see that as a benefit. Downloading and running an app to root is so 1990.

I thought Apple patched the exploits used by jailbreakme.com ages ago.

Just try to remove them...

[Anonymous Coward]

Best of all, you can't remove these w/o rooting your phone!

Re:Just try to remove them...

[Samalie]

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!

Re:Just try to remove them...

[Anonymous Coward]

As long as somebody can root my phone I'm happy.

Re:Not leaks!

[netskink]

This is goatse man.

Re:Not leaks!

[haruchai]

Grow up, retard; the goatse shit is old - much older than you'll ever be.

But Let's Vote Using Smartphones

[mtrachtenberg]

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.

Re:But Let's Vote Using Smartphones

[Dr_Barnowl]

The appropriate technology for voting is a pencil.

Anything mechanized or computerized might be splendid, efficient, and offer a whole host of other benefits. But they all lack the absolutely vital feature; the average man on the street must be able to audit it. And verily, should be required to do so.

Making a voting system where only a limited set of technocrats can audit it's veracity is madness.

Re:But Let's Vote Using Smartphones

[The Good Reverend]

Even if the voting machine is a pencil, as long as the counting machine is a computer, we run into the same issue. Sure, it can be audited, but that's not going to happen the majority of the time.

Re:But Let's Vote Using Smartphones

[mtrachtenberg]

And that's why, in addition to hand counting of the ballots at the precinct, there ought to be (at least) a digital image backup enabling complete redundant counting off the images.

The best approach would be to generate the image collection, on unchangeable media, at the precinct at the close of polls. This should probably be generated from an independent scanning station, so that the ballots can be shuffled prior to scanning. This copy should be created at the precinct, because that is where workers can check the permanent copy against the ballots themselves. Read about the Humboldt County Election Transparency Project, which has taken baby steps towards this destination.

This is a naturally distributed problem -- it would be easy for poll workers to do a 100% hand check of a permanent record of 500 images, though it might be hard to do this for a stack of 50,000 images once the ballots have been collected to a single point.

The remaining question becomes "how do I know that the digitally signed collection I receive matches that which was generated at the precinct on election night?" That, unfortunately, continues to depend on key management, as far as I can tell.

Re:But Let's Vote Using Smartphones

[Anonymous Coward]

Seems appropriate. http://www.ted.com/talks/lang/en/david_bismark_e_voting_without_fraud.html

Re:But Let's Vote Using Smartphones

[blair1q]

All voting systems have holes.

Ballot boxes can be stuffed. The counting room can be infiltrated by partisans. The entire process can be a sham run by the state's Secretary of State.

And the issues on which you base your votes can be complete bullshit designed to distract you from the true issues on which you should be making your decisions.

Nobody said plural voting wasn't a logical fallacy in the first place. It's just better than letting a guy make the decisions because he killed the last guy who made the decisions, or was the son, grandson, great^N-grandson, etc. of a guy who killed the last guy (or some guy we dug up in another country because he was a fuzzy cousin of the guy who died while making the decisions (bet you didn't know the British Royal Family is actually German)).

Re:But Let's Vote Using Smartphones

[blair1q]

The only appropriate technology for voting is raising your hand. Any device such as a ballot that can be locked in a box and carted into a locked room to be counted by strangers is eminently hackable.

The secret ballot is the single greatest threat to verity in elections since we stopped allowing the outright buying of votes.

Re:But Let's Vote Using Smartphones

[Anonymous Coward]

Yes, but raised hands make for much better targets, so second round of voting could see a sudden drop in opposition numbers. Scaring opposing voters away is a tactic used even now, even though secret voting makes it harder.

Re:But Let's Vote Using Smartphones

[elsurexiste]

Let's be honest: the average man can't audit anything. In the end, it's more about trust than technology.

Can I trust that no one will fold the ballot in a certain, unique way that would allow someone to tell it apart? Can I trust that no one will add a doodle that will equally provide a "signature"? If I can't, then I must admit there are ways to prove how someone voted.

Can I trust that no one will use the signatures describe above to identify a voter and pay/coerce? Can I trust that everyone will uphold the secrecy? If I can't, then I must admit that votes may be up for sale or manipulation.

Can I trust that no one will miscount? Can I trust that the people counting are impartial and not subject to coercion? Can I trust that, even if I'll never be present at the counting and audit the system myself, it will be carried out perfectly? If I can't, then I must admit that the whole counting thing will eventually be rigged.

There's only one reason an average man on the street trusts the system (if he does): it's familiar. Just like his trust on https, credit cards, or the expiration date of his food. Regulations for voting give trust to Average Joes and Janes because they are familiar with those measures and can somewhat understand how are they supposed to prevent rigging, not because they are effective (this is true for a lot of situations, TSA comes to mind). If people trust electronic voting systems, then they'll become the appropriate technology.

I'm sick and tired of hearing "You can't be 100% sure of X with electronic voting systems! The whole system is crap!" or "Aha! The 7th step in your chain of validations can be manipulated! The whole system is crap!". Well, it isn't. Look at elections worldwide: they are done in P&P, yet everyone says they are rigged, regardless of international (and supposedly impartial) auditing. Regardless of analysis. Just because people don't have trust in it.

We can't, therefore, judge a voting system just on how inexpugnable they are: the only thing we can do is put enough checks and barriers to make it really hard to break the main requirements, we do enough information campaigns to explain in layman terms what's going on, and we friggin' trust on the outcome. We are losing some great stuff (i.e. precision and accuracy) just because we demand things we never had and never will.

Now, let the /. crowd proceed to mod me down. But before that, my ad hominem. Your comment is group-think at its finest. Only a few people bring nice arguments to the /. table nowadays; the rest just repeats whatever the consensus is and are happy to maintain the status quo. Use your friggin' brain and don't follow the herd.

Re:But Let's Vote Using Smartphones

[blair1q]

Wait. You think you're going to be shot if you vote in public, so you don't mind a system where you can't protect your vote from simply being ignored?

Get out of my America.

Re:But Let's Vote Using Smartphones

[Anonymous Coward]

so you are saying a immigrant cannot develop a loyalty to the country they live in (or own) you are saying their children can never see the country their born in as home, that crap verges on reinforcing racism, i know americsans have stoped describing themselves as just "american" but hypenate the word with other country names, don't assume others go for that shit

Re:But Let's Vote Using Smartphones

[Anonymous Coward]

Why shouldn't I be? Public voting adds a lot to majority pressure and scare tactics possibilities. It was popular in Soviet Russia for a reason.

The ideal voting system should:
a) Let anyone check that his voice really was accounted for correctly, and
b) Doesn't let others peek on his vote, but
c) Lets everyone check everyone else's votes are counted.

It's kinda hard to satisfy all three constraints, especially when actual counting, publishing and enacting the results are still in untrusted third party hands.

Re:But Let's Vote Using Smartphones

[swillden]

You should look into Scantegrity, developed by security researchers David Chaum and Ron Rivest (the latter is the 'R' in RSA).

It is an automated, scanner-based voting system which is more secure than pencil and paper systems, precisely because it's more auditable. It actually enables each voter to verify that his or her ballot was counted correctly in the final tally -- but without giving the voter the ability to prove who they voted for to anyone else, to eliminate issues of vote coercion. The system also allows auditors (which can be anyone who is interested) to verify that no additional ballots were added to the system, and that the ballots were tallied correctly. Manual recounts can also be performed if someone doesn't trust the mathematical proofs of correctness (though the manual recounts are more likely to introduce errors than to correct them).

Technology actually can improve over the traditional ballot.

Re:But Let's Vote Using Smartphones

[mtrachtenberg]

I think you're right that auditing is a non-solution. But that only means that the counts must be easily verifiable by average persons, when motivated. The trick is to provide a solution where the average motivated person has access to enough information -- correct information -- to confirm things for themselves. The glories of redundancy will then take over, because there will often be people who are inclined to check.

As long as the signed ballot images can be confirmed to match the ballots -- and that should be a task for multiple observers at the close of a polling place -- the ballot images will enable multiple parties to come up with vote counts (and the specification of how those vote counts were arrived at.)

I only wish you were right that my previous comment was group-think. It's not. The group think is that because we bank at ATMs, we can use computers and the internet for voting. You're right that such ideas are based on the trust of the familiar. That's not good enough for voting.

Re:But Let's Vote Using Smartphones

[fluffy99]

Voting should not be another phone app. It should take a deliberate effort on the voter instead of something you can do while sitting on the crapper.

It's absolutely scary how people vote now. They blindly vote along party lines and have no clue who the candidates are, their history or even their position on key issues (not the fluff crap the media tells you is important). You'd see a radical difference if the ballots just listed names and did away with the little (D) and (R) labels. Don't even put a description of their position or say who the incumbent is. If you want to vote for someone you better at least know something about them.

Re:But Let's Vote Using Smartphones

[elsurexiste]

Well, after reading your response, my mind is at ease (I also took a nap and reached my WHO-recommended 6 hours of sleep :P ).

On the question of how easy it is to verify, I really don't know. Not because I can't come up with ideas, but because I don't know what the Average Joes and Janes would find acceptable. Maybe distributing a photo of all the motherboards involved, and using acrylic cases to display them on election day, is enough to earn their trusts. Of course, it won't do for us, tech-savvy people, and maybe nothing will. E.g., you may have ROMs that display the SHA-1 of their contents, but someone will say "How do you know that those ROMs are legit?", and so, and so, ad infinitum.

It was not your post what I thought as group-think, but Dr_Barnowl's. Your comment is actually what I would like to hear more in these debates. Most of the discussions I have with my colleagues focus on security and how at the Nth level of verifications they fail: basically they become security-related arguments in which I have to justify the mere presence of any machine more powerful than a wood stick with graphite inside. In the worst cases, they just parrot whatever the official position of the FSF equivalent in this area. Instead, I'd like to talk about what kind of things we can accomplish using electronic ballots and how. For you, it would mean true verification. For me, it would mean that the preliminary counting I saw for my ballot box will never again throw a difference between votes casted and people voting of 10% backwards (less people than votes... don't ask).

I guess I should close this with a successful experience, provided by an Estonian acquaintance: People in Estonia don't have trouble voting on the internet. I think it's crazy, even more so if you vote with your smartphone, but hey, it's a trust issue, not a technological one :) .

Re:But Let's Vote Using Smartphones

[MikeBabcock]

If you computer count all ballots and randomly hand-count some segments of ballots, you catch errors in the counting.

Not Exactly Shocking...

[Cameron Fwoosh]

Its open source, and just like ALL open source, unless the user is savy enough to lock it down, it will be vulnerable. This is especially true when you combine it with applications that are designed to run with little to no supervision. Its the same arguement that people make about Windows. The OS was designed to allow applications to be developed and run. Otherwise, Windows or Linux or any other OS could always simply develop a brick and tell developers they better know how to code in concrete...

Re:Not Exactly Shocking...

[Galestar]

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.

Re:Not Exactly Shocking...

[HiThere]

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.

Re:Not Exactly Shocking...

[Galestar]

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.

I'd have to say its more along the lines of:
a) They are more likely to be revealed (because anyone can see the code)
and
b) They are more likely to be fixed (because anyone can work on the code)

To steal from ESR's "The Cathedral and the Bazaar", Many Eyeballs Tame Complexity.

Re:Not leaks!

[jeffmeden]

Grow up, retard; the goatse shit is old - much older than you'll ever be.

(oblig.) He got you good you fucker!

Re:Its actually worse that that

[Wamoc]

This same poster did the same link earlier in the comments and it was reported as Goatse. Please mod parent down.

I love drop-through logic...

[ackthpt]

if (x < 0) {do_sfuff(); exit;}
if (x == 0) { do_other_stuff(); exit;}
if (x > 1) {
... establish restrictions ...

perform_secure_operation();

}
.
.
.
 

So... what happens when x == 1

Re:I love drop-through logic...

[thestudio_bob]

if (x if (x == 0) { do_other_stuff(); exit;}
if (x > 1) {
... establish restrictions ...

perform_secure_operation();

}
...So... what happens when x == 1

} else {
... user equals root.
}

Re:I love drop-through logic...

[Jamu]

I'm wondering what nefarious purpose the do_sfuff function has.

Re:Its actually worse that that

[Wamoc]

dev387 has posted this link 2x earlier and is a link to goatse. Please mod parent down as troll

HTC and Samsung

[ThatsNotPudding]

However, the researchers have 'experienced major difficulties' in trying to report issues to HTC and Samsung.

No problem. Just repeat your findings into one of their phones: they'll literally get the message via CarrierIQ.

Re:HTC and Samsung

[blair1q]

Or put it out in the wild where slashdot can get at it.

Re:Android sucks

[JustOK]

he tried using "Frosty piss" with Siri, but it gave him directions to closest outdoor bathroom

Goatse alert

[GameboyRMH]

For those of you who live under a rock, that's goatse. *Yawn*

Come on dude try something new. You're boring us.

This just in...

[Anonymous Coward]

Vendors are loading unwanted crapware on new machines? Wow, what a suprise

Goatse again

[GameboyRMH]

If user = dev### or href=boredgeek.evenweb.com then page=goatse

Add that to your brain's page filter script everyone.

Android = Windows 98

[Anonymous Coward]

A year ago I was excited about Android. Today I would not touch it.

Re:Android = Windows 98

[wierd_w]

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.

Re:Android = Windows 98

[Anonymous Coward]

Or just OEMs that care:

http://developer.sonyericsson.com/wp/2011/11/17/camera-libraries-available-for-sony-ericsson-phones/

Re:Android = Windows 98

[tlhIngan]

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.

Won't work. If Google imposes it as part of "With Google", the only chips available would be ones with open-source drivers. And there's very few of those, even fewer with 3D accelleration (required for Android - if you think Android is sluggish now, try it with no accelleration). In the embedded world, there are very few GPUs - nVidia's GoForce (Tegra line), Imagination Technologies PowerVR, and a few others, none of which are open-source.

Everyone else will just continue as-is, using AOSP. Until that gets relicensed as say, GPLv3 or so, in which case no one would touch it. Part of the reason why AOSP works so well is because it's Apache licensed and not GPL.

Nevermind about tablets - we'd be left with the iPad, Kindle Fire, and Nook Tablet (it appears all Android tablets are based on nVidia Tegra).

Either way, it's lose-lose for Google.

Oh, and believe it or not, some manufacturers don't want people messing around. In my dealings, I've seen them say "We don't want another xda-developers sprouting up".

Re:Android = Windows 98

[wierd_w]

I didn't say the license needed to be gpl, just open.

As for "we don't want another xda-dev sprouting up", that strikes me as the rhetoric of a dinosaur. If they said "we don't want to be put in the position where we might be forced to support 3rd party modifications" I would be sympatheric, but when they essentially epoxy the hood shut on my sportscar, because they "don't want another community-mechanics site popping up" I don't see them as anything but officious asshats.

Re:Android = Windows 98

[swillden]

The real problem with android, is that handset makers release closed source binary drivers.

While that may be a real problem, it's got nothing to do with the problem discussed in this paper.

Re:Android = Windows 98

[wierd_w]

On the contrary.

A fully open system is more easily audited. A more easily audited system is harder to hide garbage code in.

The carriers and handset makers are putting quick and dirty kludges in effect, because they want to race to market, and they feel they can get away with it.

If you make it harder for them to feel more secure (emotionally) by hiding dirt under the rug, they will make themselves feel more secure by actually sweeping up, even though that is work they apparently don't want to do.

Further, providing the community with the means to clean house for them places further incentives to get it right the first time, or risk losing relevence to a superior community produced configuration.

(See how many users prefer cyanogen, for instance.)

Re:Android = Windows 98

[swillden]

On the contrary.

A fully open system is more easily audited. A more easily audited system is harder to hide garbage code in.

Read the paper. All the code that was examined to find these issues was Dalvik bytecode, which is very easy to analyze and audit. In this case it was probably easier to audit at that level than to audit the source.

Re:Not leaks!

[haruchai]

I guess I can't expect maturity from high-numbered UIDs.

Re:Not leaks!

[slater.jay]

That's clever. Wait. They're learning? This can't be good.

Re:Not leaks!

[Anonymous Coward]

it's not just the shit is old. i think the guy is too.

Fool.

[Anonymous Coward]

It says that you didn't read the paper. The official Android devices had no cited issues, except for a minor app vulnerability -- com.svox.langpack.installer (the speech data) can be uninstalled by an unauthorized app.

Never ending vulnerabilities

[jweller13]

My god the number of Android security vuln's is a dang deluge. They really need to address this growing problem it is starting to seriously damage the brand it seems to me. I suppose this is the typical extension of being so open.

Re:Never ending vulnerabilities

[atisss]

We have to start exploiting them, writing viruses, aiming at high-value targets.
Manufacturers would start to think then..

Oh wait, they would shift the problem and install some "1 year free" antivirus crap.

Re:Software = Windows 98

[blair1q]

There. Fixed that for you.

Leaks?

[Anonymous Coward]

I thought this was going to be about memory LEAKS, not security HOLES.

Re:Not leaks!

[PNutts]

Yeah, but the classics never go out of style.

Re:Android sucks

[thsths]

Security wise - yes, most Android installations are pretty terrible. Especially if you are stuck with Froyo or some other outdated version.

There are only two real options: Nexus and Cyanogenmod. Everything else is pretty much unacceptable (especially Samsung, as nice as the hardware may be).

I never agreed to the permissions for the pre-apps

[Hyperhaplo]

So, if I never agreed to the permissions.. how can I disable their use?

And don't answer with 'root'. Rooting is not an option.

How legitimate, or legal, is it for these built in applications to access my data when I have never accepted the permissions?

Re:Android sucks

[macs4all]

Security wise - yes, most Android installations are pretty terrible. Especially if you are stuck with Froyo or some other outdated version.

There are only two real options: Nexus and Cyanogenmod. Everything else is pretty much unacceptable .

You forgot iOS. So, that's three options.