Popular Android Apps Full of Bugs: Researchers Blame Recycling of Code

New submitter Brett W (3715683) writes The security researchers that first published the 'Heartbleed' vulnerabilities in OpenSSL have spent the last few months auditing the Top 50 downloaded Android apps for vulnerabilities and have found issues with at least half of them. Many send user data to ad networks without consent, potentially without the publisher or even the app developer being aware of it. Quite a few also send private data across the network in plain text. The full study is due out later this week.

Comments

Laziness

[Anonymous Coward]

Code recycling is one thing, but not understanding what that code does when you put it into a production app or not following best practices is another. As Android gains popularity as a platform to develop for, we're going to lose quality as the new folks jumping onto the band wagon don't care how their apps work or look beyond the end goal. This mentality is already popping up with Android Wear developers who cram as much information as they can on the screen and claim that design guidelines are "just recommendations."

Re:Laziness

[AuMatar]

Design guidelines are just recommendations. Frequently bad ones. A developer should design the best UI he can, not follow what Google says regardless of whether it fits. And most developer guidelines, Google and Apple both, are crap.

The problem is that the whole app movement has brought in a whole slew of crappy developers who's idea of coding is to search stack overflow or git for stuff to copy paste. They don't read it, don't understand how to use it right, and expect it to magically work. Worse half of the people writing that code fall into the same category, so its the blind reading the blind. If you pick a library off of github and assume it will work, you deserve what you get. Unfortunately your users don't.

These people have been around for a while (they used to be "web developers" and program by copy pasting big chunks of javascript). The problem is that on a phone they can do more damage. In a world where the number of quality programmers is fixed and far less than the demand for programmers, how do you fix it? Making it easier to program actually hurts, you end up with those crappy coders trying to do even more. Maybe its time to raise the barriers to entry for a while.

Re:Laziness

[dgatwood]

Code recycling is one thing, but not understanding what that code does when you put it into a production app or not following best practices is another. As Android gains popularity as a platform to develop for, we're going to lose quality as the new folks jumping onto the band wagon don't care how their apps work or look beyond the end goal. This mentality is already popping up with Android Wear developers who cram as much information as they can on the screen and claim that design guidelines are "just recommendations."

The exact same thing happens on every other platform, though perhaps to varying degrees. I refer to it as the Stack Overflow effect. One developer who doesn't know the right way to do something posts a question. Then, a developer who also doesn't know the right way to do it posts how he or she did it. Then ten thousand developers who don't know the right way to do it copy the code without understanding what it does or why it's the wrong way to do it. By the time somebody notices it, signs up for the site, builds up enough reputation points to point out the serious flaw in the code, and actually gets a correction, those developers have moved on, and the bad code is in shipping apps. Those developers, of course, think that they've found the answer, so there's no reason for them to ever revisit the page in question, thus ensuring that the flaw never gets fixed.

Case in point, there's a scary big number of posts from people telling developers how to turn off SSL chain validation so that they can use self-signed certs, and a scary small number of posts reminding developers that they'd better not even think about shipping it without removing that code, and bordering on zero posts explaining how to replace the SSL chain validation with a proper check so that their app will actually be moderately secure with that self-signed cert even if it does ship. The result is that those ten thousand developers end up (statistically) finding the wrong way far more often than the right way.

Of course, it's not entirely fair to blame this problem solely on sites like Stack Overflow for limiting people's ability to comment on other people's answers unless they have a certain amount of reputation (a policy that is, IMO, dangerous as h***), and for treating everybody's upvotes and downvotes equally regardless of the reputation of the voter. A fair amount of blame has to be placed on the companies that create the technology itself. As I told one of my former coworkers, "The advantage of making it easier to write software is that more people write software. The disadvantage of making it easier to write software is that... more people write software." Ease of programming is a two-edged sword, and particularly when you're forced to run other people's software without any sort of actual code review, you'd like it to have been as hard as possible for the developer to write that software, to ensure that only people with a certain level of competence will even make the attempt—sort of a "You must be this tall to ride the ride" bar.

To put it another way, complying with or not complying with design guidelines are the least of app developers' problems. I'd be happy if all the developers just learned not to point the gun at other people's feet and pull the trigger without at least making sure it's not loaded, but for some reason, everybody seems to be hell-bent on removing the safeties that would confuse them in their attempts to do so. Some degree of opaqueness and some lack of documentation have historically been safety checks against complete idiots writing software. Yes, I'm wearing my UNIX curmudgeon hat when I say that, but you have to admit that the easier programming has become, the lower the average quality of code has seemed to be. I know correlation is not causation, but the only plausible alternative is that everyone is trying to make programming easier because the average developer is getting dumber and can't handle the hard stuff, which while p

Re:Not surprised

[Anonymous Coward]

Not surprised that android apps are full of holes. The whole android concept was designed to treat people like commodities in a way never before possible. The whole Ecosystem is *engineered* to have holes.

Posted from my iPhone

All software is full of bugs

[Tony Isaac]

It doesn't matter if it is Windows, Mac, iOS, Android, or Linux, all software is full of bugs.

For that matter, all of everything constructed by human beings...is full of defects, or potential defects, or security vulnerabilities. Your house, for example. You have a lock on your front door, but it takes a thief just a few seconds to kick the door in. Or your car...a thief can break into it in seconds, even if you have electronic theft protection. I'd call those "security vulnerabilities."

It's the nature of all human creations, software or hardware, electronic or mechanical.

So what do we do? We improve security until it becomes "just secure enough" that we can live with the risks, and move on.

Re:All software is full of bugs

[Greyfox]

But we don't do that. We never do that. As developers, we hide our head in the sand until we absolutely can no longer ignore then problem, and then we say "Whoops! My bad!" As consumers we assume that professionally published software should be reasonably free of bugs or exploitable code. And people start being held accountable by law for their shitty software, the status quo will never change.

I was demonstrating to a shitty software developer the other day how all his input sanitizing routines were in the javascript front end to his web application and anyone bypassing the javascript could essentially have their way with the back-end database, and he told me "Oh you're making a back-end API call, no one will ever do that!" No one except the guy who's hacking your fucking system, jackass. People like that make me want to sign on as Linus' personal dick-puncher. Whenever someone writes some shitty software that pisses Linus off, I will find that person and I will PUNCH THEM IN THE DICK. Because I swear to god, that's what it's going to take. Congress is going to have to WRITE A LAW allowing me to HUNT PEOPLE DOWN and PUNCH THEM IN THE DICK over the SHITTY SOFTWARE they write. And when that day comes, with God as my witness, I will PITCH A TENT outside MICROSOFT HEADQUARTERS, and that will be the LAST TENT EVER PITCHED at MICROSOFT HEADQUARTERS!

Re:All software is full of bugs

[Greyfox]

My programming skills are debatable but I tested in the top 10th percentile for dick-punching. Here... let me show you...

Re:What alternative could be built?

[Anonymous Coward]

Fine grained permissions. Try denying an app access to your contacts in Android. Good luck.

Code Academies

[Fnord666]

This is the sort of thing that you can expect when you put developers through a whirlwind coding course. They learn to use library after library without understanding the ramifications of their use. Need an ad network? Slap in a library. Need geolocation? Slap in a library. What you end up with are flashlight applications that want permission to read the low level system log. Then again, that's coding in the instant gratification world that we live and develop in today.

Let's see the list of spyware

[Animats]

Let's see this list of spyware. Will Google kick them out of the Android store? Will the FBI prosecute the developers for "exceeding authorized access" under the Computer Fraud and Abuse Act? If not, why not?

Re:Not surprised

[Anonymous Coward]

I'm really surprised that mine is the first comment to mention F-Droid.
Why does anyone install an app on Android that didn't come from F-Droid?

Re:What alternative could be built?

[stephanruby]

Oh, and block apps from writing to most of the external SD card, but they can do whatever they want to the internal one. Guess Google doesn't like privacy or SD cards.

That's just incorrect. For the internal memory, an app can't overwrite another app's private data, it can't even read it without special interfaces (assuming a non-rooted device). An external SD card on the other hand is deemed insecure by definition since it can easily be pulled out and placed into another device. So an external SD card was chosen as an easy way to store, share, and manage media files between different applications.

Games are underspecified

[tepples]

Why does anyone install an app on Android that didn't come from F-Droid?

I can think of two reasons. One is that someone might be using a hand me down Android device from the first year that AT&T sold Android phones, and these devices support only Google Play Store, not Unknown sources. But though I have a cousin whom this affects, I imagine few others are still on a Galaxy S 1 Captivate. A more common reason to use non-free Android apps is that free software has shown itself to be poor at producing compelling original video games. Free software works when there's a clear spec, which is true of libraries and productivity apps. But apart from maybe roguelikes, games are less specified up front unless it's a clone of an existing game, such as Aisleriot, Frozen Bubble, or StepMania. A non-free game's developer can afford to put more time into creating both the spec and the implementation.

Re:Games are underspecified

[sumdumass]

I can think of a third. I had no idea fdoid existed until reading these posts. Outside of rooting my phone ans removing a bunch of garbage, i never really looked for more than a few apps and i wont update those due to expanded permisions i find too intrusive.

That being said, now that i know, i will likely use it when i change phones again in about 2 weeks.

Re:What alternative could be built?

[Zaelath]

Mmmm, Android moved "unacceptable" into "not unusual" at the same time and said a lot more apps "require no special permissions", despite needing Device ID, GPS, and storage access. You know. For a torch app.

Re:Not surprised

[Cryacin]

All the app developers want this for Christmas:

http://www.shutterstock.com/pi...

Load of ignorant crap

[janoc]

The entire article is harping on 3rd-party ad network libraries stealing personal data and phoning tracking info home. As these are libraries and developers are re-using open source libraries, then it follows that "Open source is no free lunch" and is stealing your data. What a majestic leap in logic!

They conflate open source libraries with various ad-network code stealing personal data, basically trying to portrait open source code as being responsible for it. Never mind that the ad-network code is almost never open source.

Granted, OSS is certainly not bug-free, but the spyware has little to do with it.

What a load of ...

Re: What alternative could be built?

[EmperorArthur]

Internal memory and internal SD card are two separate things in Android. Internal SD card is simply a part of the internal NAND that the OS treats like a normal SD card. Many phones don't support external SD cards but have moderate amounts of storage, so they compromise.

I'm not sure I follow.

Many phones don't support external SD cards, but officially their apis still need to support external storage with internal SD memory anyway, otherwise they won't pass the Compatibility Test Suite.

The problem is that the internal SD card and external SD card are treated differently.

Android apps by default work off the internal SD card. It's actually a separate partition that's mounted at the same place as old phones used for external SD cards. You can't change the default to use an external card. You can't recover space from that internal partition.*

Here's the kicker. Now external SD cards are mounted somewhere else. (/mnt/extSD) The thing is that many apps don't work with the external SD card. Especially after the latest android release. With android KitKat apps with the, misnamed, external storage permission can read and write anywhere on the internal card. The problem is that now they can read anywhere on the external card, but can only write to a directory on it which is something like "/mnt/extSD/data/app.name" There are a few exceptions for system apps like the camera, but regular apps have to use this weird naming scheme.

It's actually a good security feature, but the fact they don't apply it to the internal SD card just seems to be Google deliberately moving people away from phones with an external SD card. Not cool.

*Without rooting, and knowing exactly what you're doing at least. No way a non expert is doing this.