Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about 3 months ago | from the little-of-this-little-of-that dept.

Android 150

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.

cancel ×

150 comments

Sorry! There are no comments related to the filter you selected.

Not surprised (0, Flamebait)

Noah Haders (3621429) | about 3 months ago | (#47547415)

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.

Re:Not surprised (5, Funny)

Anonymous Coward | about 3 months ago | (#47547427)

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

Re:Not surprised (2, Funny)

Anonymous Coward | about 3 months ago | (#47547437)

Not surprised that iPhone apps are full of holes. The whole Apple 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 Android phone

Re:Not surprised (3, Funny)

JustOK (667959) | about 3 months ago | (#47548283)

True. --Posted from YOUR phone.

Re:Not surprised (4, Funny)

Cryacin (657549) | about 3 months ago | (#47548133)

All the app developers want this for Christmas:

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

What alternative could be built? (2)

tepples (727027) | about 3 months ago | (#47547429)

How would an ecosystem be designed not to have these sorts of holes but also not to restrict what the owner of a device can use it for?

Re:What alternative could be built? (2, Interesting)

EmperorArthur (1113223) | about 3 months ago | (#47547443)

How would an ecosystem be designed not to have these sorts of holes but also not to restrict what the owner of a device can use it for?

Just look at the Xprivacy extension for rooted android phones. Even iPhones let you disable app permissions. What has Google done about the issue? They reduced permissions into groups so users couldn't even know exactly what their apps have access to any more. 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.

Re:What alternative could be built? (4, Informative)

stephanruby (542433) | about 3 months ago | (#47547479)

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.

Re: What alternative could be built? (1)

Anonymous Coward | about 3 months ago | (#47547551)

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.

Re: What alternative could be built? (1)

Anonymous Coward | about 3 months ago | (#47547869)

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 [android.com] .

Re: What alternative could be built? (4, Interesting)

EmperorArthur (1113223) | about 3 months ago | (#47548175)

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 [android.com] .

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.

Re: What alternative could be built? (3, Informative)

johanw (1001493) | about 3 months ago | (#47549171)

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

Depends on the phone. I have a cheapass Android phone with only 4GB of internal memory, but it let me choose (out of the box, no root-only tricks here) wether I want the internal memory or the physical microsd card mounted as /sdcard0 or /sdcard1. The phone switches them if you like (and that is very reccommended with this little internal memory).

Re:What alternative could be built? (4, Informative)

Zaelath (2588189) | about 3 months ago | (#47547643)

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:What alternative could be built? (2)

johanw (1001493) | about 3 months ago | (#47549123)

" Oh, and block apps from writing to most of the external SD card"

SDFix to the rescue. Requires root but if you're running XPrivacy you already have that. It saved my Sygic installation after I upgraded to 4.4.

Re:What alternative could be built? (4, Insightful)

Anonymous Coward | about 3 months ago | (#47547449)

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

Re:What alternative could be built? (1)

johanw (1001493) | about 3 months ago | (#47549187)

Easy. XPrivacy. Requires root, but I would rather use Symbian than an unrooted Android.

Re:What alternative could be built? (2)

djupedal (584558) | about 3 months ago | (#47547591)

How would an ecosystem be designed not to have these sorts of holes but also not to restrict what the owner of a device can use it for?

What..._and_ make money? Will you settle for 2 out of 3? But first, define 'restrict' and don't point to other platforms, thanks.

I define restrict (1)

tepples (727027) | about 3 months ago | (#47548763)

I understand your fear of falling into a definition trap. I define restrict as A. refusing to make an API for reasonable uses of hardware features, such as no way for an app to see which SSIDs are nearby or no way for web apps to draw 3D scenes or upload data types other than photos and videos, or B. requiring a recurring fee or an organizational background check to run software that you compiled on a machine that you own.

Re:Not surprised (0, Troll)

Anonymous Coward | about 3 months ago | (#47547441)

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.

Do they pay you in MSFT stock or cash?

Re:Not surprised (1)

Anonymous Coward | about 3 months ago | (#47547527)

No, I think he a Unix-Grey-beard with hatred of Garbage Collection. {:==={{}}}

Re:Not surprised (5, Informative)

Anonymous Coward | about 3 months ago | (#47547473)

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

Games are underspecified (4, Informative)

tepples (727027) | about 3 months ago | (#47547509)

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 (1)

Anonymous Coward | about 3 months ago | (#47547549)

compelling original video games

So you're talking about Candy Crush, right?

Re:Games are underspecified (1)

johanw (1001493) | about 3 months ago | (#47549217)

Another reason: I want to be able to reinstall everything manually so I keep installers. No need to hassle around with stores or repositories when you can have apk's.

Re:Not surprised (2, Insightful)

stephanruby (542433) | about 3 months ago | (#47547943)

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

Aside from the fact that I don't like any of the games [f-droid.org] F-Droid has to offer.

It's because...

Wait for it, wait for it...

...I don't really care. Believe it or not, but not everyone is as privacy conscious as you are.

Re: Not surprised (1, Interesting)

Anonymous Coward | about 3 months ago | (#47548573)

You know what else? Nobody cares that you're not privacy conscious, and quit trying to turn the term into some kind of insult. It's not, but simple minds kind of annoy the rest of us.

Re:Not surprised (1)

Anonymous Coward | about 3 months ago | (#47548721)

...I don't really care. Believe it or not, but not everyone is as privacy conscious as you are.

That makes you an idiot, and that's your problem.

The rest of us have no desire to hand all of our personal information over to marketing people.

Go ahead, embrace your own stupid, but own the consequences of it. And don't expect us to do the same.

Re:Not surprised (3, Informative)

Dutch Gun (899105) | about 3 months ago | (#47548325)

How many reasons would you like? F-Droid has about a thousand apps to the Play store's 1.2 million. You have to install it through side channels. Relatively few in the mainstream have heard of it. None of the apps that people's friends or favorite websites are talking about are available on it. A quick peek at some of the new apps listed on the front page reveal these potential blockbusters:

* A guessing game: try to guess a number between 1 and 100 in under eight tries
* A ROT-13 encoder/decoder
* An ASCII/Hex/Ocal/Binary converter
* Swimming distance calculator
* TI graphing calculator emulator (no ROMs included)

It surprises you that people aren't flocking to this in droves? Look, nothing against F-Droid. It's cool that people are doing this, but let's keep our expectations grounded in reality.

Re:Not surprised (0)

Anonymous Coward | about 3 months ago | (#47548727)

Thanks for the link

Re:Not surprised (2)

NotInHere (3654617) | about 3 months ago | (#47547517)

When I've had no android, I've thought that too. But as I've purchased an android phone, I was quite impressed about the efficient and tight rights separation system of android. Don't misunderstand me: I didn't "activate" the play store app, as I needed to couple it with a google account. If you could install the free apps without an account I'd have tried it, but that way google had lost a customer. The next thing I was annoyed of was the samsung bloat, and the possible lock-in the case I really started to like one of those apps. I solved these two problems when I've installed CM and F-Droid. Of course, I can't install the fanciest whatsapp and so on, but at least I know my phone is truly mine (except for the baseband part), and that lock-ins are very hard. I was fascinated when I found out that every installed app has its own UNIX user assigned.

The rights separation in android is far more better than anything on the linux desktop. In X, every application can keylog me. In android, that's not possible. On the linux desktop, every application has access to all my files [xkcd.com] , including my .ssh directory.. In android, fs access is far more developed and limited. In linux desktop, every app has access to the webcam. In android, you can see which app has access. Of course, android could do better, perhaps by adding a "revoke right" option and an "always ask" option (osmand for example has a nice recorder feature, but most time I use it I don't need it so why does it have the right *all time*, rather let android ask for that permission the few times I need it), but right now it does best.

The most annoying features of the android ecosystem radiate from GAPPS, but almost none from AOSP.

Re: Not surprised (0)

Anonymous Coward | about 3 months ago | (#47547737)

Proprietary baseband and proprietary firmware. Try Repliant.

Re:Not surprised (2)

brantondaveperson (1023687) | about 3 months ago | (#47547953)

perhaps by adding a "revoke right" option and an "always ask" option

You mean, just like iOS? Actually, Apple may very well have a patent on that which might explain why Google hasn't yet adopted this obvious paradigm.

Re:Not surprised (1)

TheRaven64 (641858) | about 3 months ago | (#47548309)

I doubt Apple has such a patent. Both of these were features of Symbian at least since EKA2 (over 10 years ago) and, I think, earlier. Apple may have a patent on some particular way of exposing this functionality to the UI, but that's about the most that they could have without it being shot down in court in 10 seconds (prior art that's in the form of a phone OS that millions of people owned is hard to refute).

Re:Not surprised (0)

Anonymous Coward | about 3 months ago | (#47548449)

Except that the patent system was changed from first to innovate to first to file. Apple patented slide to unlock, and the fact that there was a commercial phone running windows CE released in 2005, 2 years prior to the iPhone, that used a slide to unlock that was identical to Apples didn't stop them from getting the patent.

Re:Not surprised (1)

Anonymous Coward | about 3 months ago | (#47548671)

First to file doesn't magically remove prior art, does it? If they didn't invent it they can't patent it.

Re:Not surprised (1)

MightyMartian (840721) | about 3 months ago | (#47547679)

I'm not clear as to how, for instance, using buggy versions of SSL libraries fits into your whole theory. One possibility is that what you wrote is gibberish.

Laziness (4, Insightful)

Anonymous Coward | about 3 months ago | (#47547425)

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 (5, Insightful)

AuMatar (183847) | about 3 months ago | (#47547493)

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 (3, Informative)

Lennie (16154) | about 3 months ago | (#47548597)

Crappy developers usually means: uneducated developers.

They can get simple things done without understanding the whole system. That deliver something that sort of works. This makes them cheap labor.

Why do we need cheap labor, because of competition and a race to the bottom driven by consumer buying decisions.

In a talk by Gabe Newell from Valve said that a free game got you 10x more users and 3x more profit (they for example get some money from people selling items inside the game). Not that they use cheap labor, they actually do the exact opposite. But it is just to illustrate how price is important.

So free like the above is a profitable model, free and ad-supported might actually not be as profitable. I don't know how much money companies get for selling personal information. I assume it is more than the ads.

So how do you solve that.

I see a few possible ways:
- education
- create good open source libraries that prevent most of the bad things and cheap developers want to use.

Now comes the kicker:

Do you think HTML5-apps without any permissions by default on phones would be a better model ? :-)
That would be a model similar to Javascript-code running in the browser on the desktop where the user is asked to allow access to the camera when needed.

Actually, I do, but then again I actually do use a FirefoxOS phone to see what it is like.

A lot of the time the hardware is bit underpowered so it can be sold in countries that currently still have a large number of feature phones or people not willing/able to pay for more expensive hardware.

But still pretty impressive what they can get out of that cheaper hardware.

Re:Laziness (0)

Antique Geekmeister (740220) | about 3 months ago | (#47548639)

> They can get simple things done without understanding the whole system. That deliver something that sort of works. This makes them Java developers.

Fixed That for You.

[ Note grammatically correct but confusing capitalization, another of my pet Java peeves. ]

Re:Laziness (5, Informative)

dgatwood (11270) | about 3 months ago | (#47547725)

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 possible, is even more cynical than the original assertion and makes me weep for the future.

Either way, there's something really, really wrong at a fundamental level with the way we search for solutions to coding problems. There needs to be an easy way to annotate the fact that a code snippet was derived from a particular forum post, and to automatically receive email notifications (or bug reports) whenever someone flags the snippet on the original forum as being wrong or dangerous. And we as developers need to take the time to learn enough about the OS and the programming environment to ensure that we at least mostly understand what a piece of code does before we ship it in a product.

Re:Laziness (0)

Anonymous Coward | about 3 months ago | (#47548121)

Oh, so that is what it is called. I have always called it the Java way.
Documentation that only tells you what functions exists and not why they exists and what the intended use is leads to that kind of coding.

Re:Laziness (1)

gbjbaanb (229885) | about 3 months ago | (#47548703)

I'll agree there - thought its not Java at fault necessarily - not unless you lump in a bunch of other languages like VB, C#, JS etc.

The problem is of the library code you're using. Libraries should be small, well defined, easy to use, and documented.

The problem today is (especially with code written in Java, .NET or JS) that it is knocked up to solve some problem but the problem is not only not properly understood, but the code that is provided doesn't solve it particularly well. Its not defined as a discrete task, more as part of some greater whole that someone thought "worked ok for me in my circumstances, so should be fine for others too".

If libs were properly specified as libraries and their API documented fully, then we would see more code reuse and better, cheaper code. If only, but the cost of making such a library tends to be too slow and difficult for the 'I want it now' majority, and this is why we continue to have this kind of shitty code problem.

Re:Laziness (1)

mean pun (717227) | about 3 months ago | (#47548303)

Although you certainly have a point, the core problem is often that the documentation is poor. I find that if there is a proper writeup of the solution somewhere on the net, Stack Overflow will mention it (eventually). If there is no proper writeup, sometimes someone bright posts a solution that is right, and sometimes people stumble upon a voodoo solution that nobody understands properly, but sort-of works.

The Android APIs are susceptible to this problem, because they are often poorly documented, have glaring documentation bugs, or don't explain the overall concepts. No matter how brilliant your epibration classes are, and no matter how well-documented all the methods in the epibration API are, it doesn't help at all if you don't explain what the hell epibration is, and when and how you should use it.

Amazingly, security libraries are often in this category. Is there a really good writeup ANYWHERE about SSL, certificates and signing practices? And IPSec with all its intricacies?

Re:Laziness (1)

dkf (304284) | about 3 months ago | (#47548465)

Amazingly, security libraries are often in this category. Is there a really good writeup ANYWHERE about SSL, certificates and signing practices? And IPSec with all its intricacies?

Funnily enough, on Stack Overflow! Not all of the security-related questions are overflowing with shitty misinformation. (SO might not be great, but it's better than the squillion shitty places for question answering that preceded it.)

Re:Laziness (1)

mpe (36238) | about 3 months ago | (#47549107)

Although you certainly have a point, the core problem is often that the documentation is poor.

A not uncommon problem being "solutions" which omit steps or assume that everyone knows how to find, what is in practice, an obscure option. Sometimes also having "boilerplate" which overexplains another part of the process.

Amazingly, security libraries are often in this category. Is there a really good writeup ANYWHERE about SSL, certificates and signing practices?

That would also have to include TLS, STARTTLS, how it can really be STARTSSL, etc. There's also the issue of what is actually part of the protocol and what is implimentation specific.

Re:Laziness (1)

TheRaven64 (641858) | about 3 months ago | (#47548363)

The problem is worse on Android than on many other platforms because there are very few native shared libraries exposed to developer and there is no sensible mechanism for updating them all. If there's a vulnerability in a library that a load of developers use, then you need 100% of those developers to update the library and ship new versions of their apps to be secure. For most other systems, core libraries are part of a system update and so can be fixed centrally.

Re:Laziness (1)

mpe (36238) | about 3 months ago | (#47549147)

The problem is worse on Android than on many other platforms because there are very few native shared libraries exposed to developer and there is no sensible mechanism for updating them all. If there's a vulnerability in a library that a load of developers use, then you need 100% of those developers to update the library and ship new versions of their apps to be secure. For most other systems, core libraries are part of a system update and so can be fixed centrally.

It used to be very common with MS Windows for libraries to be bundled with applications. A situation called "DLL hell". Which can be even worst when an application installer tries to update a "system" copy of the library.

Re:Laziness (1)

dotancohen (1015143) | about 3 months ago | (#47548885)

You are going to hate what the Neovim folks are trying to do to VIM's learning curve:
https://github.com/neovim/neov... [github.com]

I fear the day when Eternal September comes to VIM.

Re:Laziness (1)

mpe (36238) | about 3 months ago | (#47549019)

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.

There are also cases where using a self signed certificate is rather more secure than using a CA to. The whole CA idea having all sorts of problems.
Though the example is one of those where only someone who didn't understand how things worked would need to ask such a question in the first place.

Re:Laziness (1)

Neil Boekend (1854906) | about 3 months ago | (#47548279)

Probably mostly speed. Understanding every tool you use means you must invest time to understand it. In the swift and agile world of app development security is the first victim. Taking time to understand what you are doing seems to be outdated.
The only thing the users can do is not install apps that request rights they have no need for. Sadly most users do not care.

Re:Laziness (2)

Lennie (16154) | about 3 months ago | (#47548369)

It's the price that is driving this, when an app is free or just 1 dollar, this gives a lot of reasons to not spend a lot of time on it.

Re:Laziness (1)

narcc (412956) | about 3 months ago | (#47548613)

How about "pride in your work"? Remember that old maxim "anything worth doing is worth doing well"?

I simply can't believe that money is the only thing that motivates people.

Re:Laziness (0)

Anonymous Coward | about 3 months ago | (#47549007)

How about "pride in your work"? Remember that old maxim "anything worth doing is worth doing well"?

I simply can't believe that money is the only thing that motivates people.

Well, maybe it isn't the only thing that motivates developers, but it certainly tends to be the only thing that motivates people who pay developers ...

Re:Laziness (1)

jareth-0205 (525594) | about 3 months ago | (#47548701)

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.

No developer completely understands everything that happens on a system, that's impossible. You do your best and you verify as well as you can that it's acting as you expect. Because where else do you stop..? You can't verify every library that you use, otherwise why bother using them, you might as well write your own. You can't verify the system itself because it's far too big.

Not that I'm saying things couldn't be written better, but programming is not a "correct / incorrect" binary choice, any nontrivial system has problems.

All software is full of bugs (4, Insightful)

Tony Isaac (1301187) | about 3 months ago | (#47547447)

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.

Type system helps find bugs early (1)

tepples (727027) | about 3 months ago | (#47547531)

Our add features to a language that help the programmer prove that certain defects are not present. Bounds checked arrays are a big one compared to plain C, but others exist. Rust, for example, has separate types for "pointer that can never be null" and "pointer allowed to be null", and it is a compile-time error to pass the latter to a function expecting the former outside of a construction that means essentially "if null then do X else do Y".

Or research methods of containing the damage that a defect can do. Android, with its overly broad permissions, has tended to fall at this.

Re:Type system helps find bugs early (1)

Anonymous Coward | about 3 months ago | (#47547617)

Until the saviour rust browser engine descends from heaven to rule the earth we have to live with the sign of the gecko beast on our forehead. Before servo delivers us from the zeroth day on the last day, a huge fox with fire will be cast into the hdd: and the third part of the hdd shall become blood; And the third part of the tabs which were on the gecko, and had life, died; and many processes will die of the memory, because the memory will be have been made bitter.

From The Book of Mozilla, the word of LORD.

Re:Type system helps find bugs early (0)

Anonymous Coward | about 3 months ago | (#47547765)

Our add features to a language that help the programmer prove that certain defects are not present. Bounds checked arrays are a big one compared to plain C

Bounds checking in C has been a standardized extension since 2007. (ISO/IEC TR 24731)
It is briefly covered in "Annex K (normative) Bounds-checking interfaces" of the ISO-C standard.
If the implementation you use has _ _STDC_LIB_EXT1_ _ set it supports it. If you need to show that the program does bounds checking then use it.

If you want t go the extra step to ensure that your code works as intended you can always write it to be MISRA C [wikipedia.org] compliant or whatever guidelines you think are needed. Then you have multiple tools that validates your code while you still get the performance benefit of C.
On that matter, how many of the "safe" languages are actually certifiable for human safety relevant implementations?

Not allowed to quote MISRA C rules (1)

tepples (727027) | about 3 months ago | (#47548807)

I would recommend MISRA C, but it's impossible to make a conformance checker under a free software license because quoting the rules in error messages appears to require an incompatible copyright license. Source: presence of the word "prices" in the section "I am a tool vendor" in the official FAQ [misra-c.com] .

Re:All software is full of bugs (5, Funny)

Greyfox (87712) | about 3 months ago | (#47547567)

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 (0)

Anonymous Coward | about 3 months ago | (#47547597)

Says the person who is likely a shitty programmer themselves.

Re:All software is full of bugs (4, Funny)

Greyfox (87712) | about 3 months ago | (#47547691)

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

Re:All software is full of bugs (1)

Lennie (16154) | about 3 months ago | (#47548405)

1. Why are you excluding women ? isn't that discrimination ?

2. Some people just don't know this yet, they don't have a hacker mentality (which is what is needed to understand whole systems and how things can be used in ways they were never intended). A hacker mentality is not taught at educational institutions, so they need to still learn it. It usually isn't malice or laziness it is not understanding what you are doing. All they have learned is is how to get the task completed.

Re:All software is full of bugs (0)

Anonymous Coward | about 3 months ago | (#47548959)

I would like to amend your law to SUCK THEM IN THE DICK, so i can enjoy many dick sucks.

Re:All software is full of bugs (2)

WaffleMonster (969671) | about 3 months ago | (#47547745)

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

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

Who cares about the security of an untrusted and untrustworthy app in the first place?

What difference does it make if it was written by the most competent team of programmers in the world if while operating as designed still treats the end user with contempt?

Re:All software is full of bugs (2)

gringer (252588) | about 3 months ago | (#47547749)

For that matter, all of everything constructed by human beings

You might not be terribly surprised to know that our genes (and the genomes of pretty much everything) are also full of bugs. We have a whole raft of deleterious genetic variants in our DNA that are just waiting for the perfect time to activate and say "hey, you know that life thing? I can make it worse." On top of that, we have a few viral genomes in our DNA (possibly some that are still active), and rely on bacteria and mitochondria to provide us with energy required to live.

In other words, defective objects are the rule, not the exception.

p.s. hmm... I've only just realised how much I miss that handy login form that SoylentNews has to deal with accidental AC posts.

Re:All software is full of bugs (3, Insightful)

jmv (93421) | about 3 months ago | (#47547835)

Software on Internet-connected devices is a bit different from your examples though. No matter how insecure cars are, it would be really hard for me to steal a million cars in one night, let alone without being caught. Yet, it's common to see millions of computers/phones being hacked in a very short period of time. And the risk to the person responsible is much lower.

trivial! (1)

martin-boundary (547041) | about 3 months ago | (#47547945)

That's trivial. It's like saying, there are only two numbers, "zero" and "many". It simply isn't true that all languages and all platforms are full of bugs in any meaningful sense. Some platforms are more buggy than others. This is a function of how old the platform is, how serious the creators are about preventing bugs, etc. That's meaningful.

For example, the well known OpenBSD aims to be much more secure than other OSes. The well known Windows family doesn't care about security, only as an afterthought. The difference is striking and very well known.

A good way to estimate which systems are likely to have fewer bugs is to understand the motivation of the application developers and of the OS creators. For example, if your focus is advertising, then you have a natural blind spot where advertising bugs are ignored. If your focus is doing "easy to use" software, then you have a blind spot where security practices are compromised in favour of GUI issues.

Re:All software is full of bugs (1)

thegarbz (1787294) | about 3 months ago | (#47548025)

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

Who's perspective are you talking about?
The risk of the user being compromised? Or the risk of the programmer being held accountable?

For the most part we're not talking about fixing all bugs. For the most part the argument isn't even about being "secure enough".

No. For the most part some of the bugs are outright inexcusable.

But open source cures all that ails us, right? (1)

Anonymous Coward | about 3 months ago | (#47547465)

We can just edit the source, and compile new versions, that work properly?

Seriously, a system is only as good as its process. And the open-source process is not necessarily any better, it can be, but it need not be.

Re:But open source cures all that ails us, right? (1)

tepples (727027) | about 3 months ago | (#47547537)

No major video game publisher is going to let unaffiliated individuals see the game's source code.

Except Id (1)

tepples (727027) | about 3 months ago | (#47547555)

Correction: I meant within the first few years. A few PC game developers such as Id release source code a couple engine generations back.

Re:Except Id (0)

buckfeta2014 (3700011) | about 3 months ago | (#47547587)

When was the last time that iD has made a game that was relevant? The last one that comes to mind is RTCW: Enemy Territory.

Code Academies (5, Insightful)

Fnord666 (889225) | about 3 months ago | (#47547467)

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.

Re:Code Academies (-1)

Anonymous Coward | about 3 months ago | (#47547683)

Exactly, and that is the fault of the Republicans with their perverted drive for money. Almost always, the ruler of a company is one of their kind, and they will not allow the time to be spent to make apps secure, or even work well. Instead, they hate the people they steal from. Once they get your 99 cents, they then want to make sure the app doesn't work so you'll spend another 99 cents in an attempt to find something that works.

Re:Code Academies (2)

thegarbz (1787294) | about 3 months ago | (#47548031)

I wonder what the opposite would look like.

Just imagine a world where you had no libraries and had to manually code everything. What would that world look like? No developers? No consistency for end users? Do you think security would be better when developers are forced to write more code?

Somehow I don't think the libraries are necessarily the problem.

Re:Code Academies (0)

Anonymous Coward | about 3 months ago | (#47548329)

Well. Did I read wrong? He didnt accuse libraries to be the problem.

> They learn to use library after library without understanding the ramifications of their use

Developers are the problem :-) Those cheap fly by night ones that know how to use libraries... only

Re:Code Academies (1)

swb (14022) | about 3 months ago | (#47548423)

I'd guess it would look like the Apple ][ or the very early days of the IBM PC and there would be just less functionality.

Re:Code Academies (1)

gbjbaanb (229885) | about 3 months ago | (#47548725)

you'd have a vast library of libraries. Something like CPAN or something you'd get in the C world. Libraries written to perform some task and nothing more. Then documented with care and the API published.

Anyone wants to do something, they take the library that appeals to them and adds it to their program and build up a program from these bits.

Now the problem today is that a) some only use libs that come with the OS or language framework, b) the libraries that are out there are shit, written quickly and for a bit of a mishmash of scenarios.

For example, you can get an XML parser and it will work perfectly. It will only parse XML though, but then, that's what only what you want from a XML parser library! .... well, except it also comes with network routines and specialised SOAP parsing and a suite of http helper methods, including a web services subsystem :-(

So the problem is not so much that we have libraries, but that the libraries we have are not good enough as library code.

Re:Code Academies (0)

Anonymous Coward | about 3 months ago | (#47548251)

This is the sort of thing that you can expect when you put developers through a whirlwind coding course.

Do you know the internals of a simple "CreateThread" or even a "WriteFile" function call (both Kernel32) ? Below the level of what its supposed to do ofcourse

Well, neither do I, and I pride myself in wanting to know those in-and-outs.

The reason is simply because there are too many of them to get to know intimatily. And thats apart from the problem that they can change between the versions of the/an OS.

Yes, I think that there are people that will just add a library because a small part of it will, according to the specs of that lib, do what they want.

But how are those people different from the accomplished C(whatever) programmers which do not see a problem to use a 'printf' where a 'puts' would suffice ?

Besides, any compiler worth its salt should be able to only include the parts it actually needs (remove as much "dead" code as possible). If that can't be done, who is to blame ? The programmer using the library, or the person who created it ?

Granted, there will be a number of programmers who could care less about violating the users wishes, and will add whatever code (advertisments, datamining and even downright malware) will gain them money the fastest.

Than again, there are quite a few users which could care less if the programmer is payed for his efforts, and will easily "steal" software.

The problem is that the good ones among both groups have to suffer because of a few (i hope) bad apples.

Captcha: lynched - How oddly fitting.

Let's see the list of spyware (4, Interesting)

Animats (122034) | about 3 months ago | (#47547469)

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:Let's see the list of spyware (1)

tlhIngan (30335) | about 3 months ago | (#47547621)

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?

Easy, the summary says they analyzed the top 50 downloaded apps. So your list of spyware will be those.

As for Google, well, Google owns online marketing advertising market, so those apps really are helping Google in the end...

What did you expect would happen (1)

Anonymous Coward | about 3 months ago | (#47547475)

When the user has zero control over what is running on their device and what is communicated by their device, things like this will happen over and over again.

Re:What did you expect would happen (1)

Desler (1608317) | about 3 months ago | (#47547603)

These are apps people have to choose to install and run. How do they have zero control when they chose to install them?

User control of apps post-install (0)

Anonymous Coward | about 3 months ago | (#47547735)

The parent was referring to user control of what apps are allowed to do after they are installed.

You know, just like users have control over applications on all their other computer machinery post-install, either through changing filestore permissions, or firewall rules, or using jails or containers of one kind or another --- normal practice for anyone who values their privacy and security. It's only Android that disallows this among Linux-based systems.

Re:User control of apps post-install (0)

Anonymous Coward | about 3 months ago | (#47548169)

This level of control is available if you have root on your Android device. If not, well, just try setting iptables rules without superuser rights on Linux, then tell us again how all this is such a stark contrast.

Re:What did you expect would happen (0)

Anonymous Coward | about 3 months ago | (#47547775)

The only reason that comes to mind why someone might not want users to have fine control over their running apps is if they benefit criminally or otherwise maliciously from the user's lack of control.

Re:What did you expect would happen (0)

Anonymous Coward | about 3 months ago | (#47547811)

This! Or it's just cheaper and easier.

Re:What did you expect would happen (0)

Anonymous Coward | about 3 months ago | (#47548209)

How do they have zero control when they chose to install them?

Maybe you should learn to read in context before you open your mouth ?

Yes, a user has the choice to download and install software. And that is than exactly the only choice he has. He also has to make that choice based on information that is given to him by the writer/seller of that software.

Which is often less-than-honest. like "forgets" to mention all kinds of implicit contracts with third-parties, which than can range from in-game advertisement to "just" datamining of the phone the game is running on.

All other choices, of which there are many, are out of the hands of that user.

Buck feta. (-1, Flamebait)

buckfeta2014 (3700011) | about 3 months ago | (#47547577)

Buck feta.

Good job editors (0)

Anonymous Coward | about 3 months ago | (#47547605)

What a perfect segue from the previous article..

Ignorance is bliss (2, Insightful)

WaffleMonster (969671) | about 3 months ago | (#47547665)

TFA is being much nicer than Google and many app vendors deserve.

The whole ecosystem system is engineered to reward bad behavior /w complete lack of usable access controls speaking for itself.

They need only do the minimum required to keep all hell from breaking loose and too many people bailing on the platform as a result.

Load of ignorant crap (5, Insightful)

janoc (699997) | about 3 months ago | (#47548135)

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

"Free" mentality (1)

drolli (522659) | about 3 months ago | (#47548231)

yeah. as long as the custoemers dont even care about any security, but about a shiny interface and are not willing to pay, focusing on the interface and not on the security of the app seems like a reasonable economic decision to me.

Today: Researchers Blame Recycling of Code (2)

Tanuki64 (989726) | about 3 months ago | (#47548257)

Tomorrow: Researchers Blame "Not invented here" mentality.

Instead of using tested standard libs, developers constantly reinvent the wheel.

The choice (1)

Geeky (90998) | about 3 months ago | (#47548273)

The choice seems to be between the flexibility of Android vs. the (arguably?) better security on iOS.

I'd like to be able to install Android apps without having to accept all of the permissions they require, but without rooting my phone that's impossible. As a result, there are many apps I just won't install (it took me ages to find a torch app that didn't need anything beyond access to the camera, for example).

On the other hand, I love widgets - quick access to information and actions from the desktop is really useful and the iOS 8 version doesn't look like it'll be as flexible.

Ultimately though I'll be looking very closely at the iPhone 6 when it comes out because Android just won't address the concerns around security.

How has slashdot come to this? (1)

lippydude (3635849) | about 3 months ago | (#47548835)

Who's paying these researchers at Codenomicon to research Android vulnerabilities? Howard A. Schmidt, Chairman of the Board [codenomicon.com] at Codenomicon.

Some people might have been providing a vulnerability on purpose in order to do something nasty .. Who are they working with? Do they have sideline jobs somewhere else? The developers might be getting their dollars from ad networks"

Is this what slashdot has been reduced to, regurgitating anti Open Source FUD on behalf of a most probably a false-front for the MICROS~1 organization?

Headline first, results later (0)

Anonymous Coward | about 3 months ago | (#47548909)

I'd be more impressed if these people let their findings speak for themselves. Grabbing headlines first, saying the results will be out later, suggests that the results will be picked apart later and there won't be much to them. But these people will have grabbed their headlines already, and no one reads detailed analysis of old results that made headlines earlier in the week.

If the results are meaningful, let them speak for themselves.

Recycling Code? (1)

Murdoch5 (1563847) | about 3 months ago | (#47549063)

Why on earth would you recycle code, that is rookie programming error 101. Every program you write needs to use a fresh and clean set of functions and structures, because how else can you get everything to fit together perfectly.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?