Slashdot Mirror
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.
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.
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."
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?
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.
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.
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.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
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?
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.
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.
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.
Correction: I meant within the first few years. A few PC game developers such as Id release source code a couple engine generations back.
What a perfect segue from the previous article..
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.
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.
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.
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 ...
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.
Tomorrow: Researchers Blame "Not invented here" mentality.
Instead of using tested standard libs, developers constantly reinvent the wheel.
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.
Sigs are so 1990s. No way would I be seen dead with one.
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.
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.
Who's paying these researchers at Codenomicon to research Android vulnerabilities? Howard A. Schmidt, Chairman of the Board at Codenomicon.
.. Who are they working with? Do they have sideline jobs somewhere else? The developers might be getting their dollars from ad networks"
“Some people might have been providing a vulnerability on purpose in order to do something nasty
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?
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.
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.
They found issues with at least Half of them. If they hadn't been re-using code, they'd (eventaully) be finding issues with ALL of them!
You're correct, as far as I can tell. First to file changes only how conflicts are resolved when two patent applications pending at the same time claim the same invention. It does not remove the novelty requirement, which means that an inventor is still not entitled to a patent if someone else publishes the invention before the inventor applies for a patent.
So I have two guesses as to how the Windows CE thing came about. Either Fingerworks licensed the patent to Microsoft before Apple acquired Fingerworks, or Microsoft released Windows CE less than 18 months after Fingerworks applied for the patent.
It's like saying, there are only two numbers, "zero" and "many".
Some people believe that either something is secure or it's not, just like a woman is pregnant or she's not, or a dish is vegan or it's not. But to head off an imminent definition debate, let me explain your core idea in terms they'll understand:
Virtually all off-the-shelf software is insecure. People take out errors and omissions liability insurance ("E&O") to cover their behinds in case a vulnerability causes a noticeable problem. You may call software "more secure" if it has had its vulnerable surface reduced, and you may call software "acceptably secure" if it is more secure to the point where the cost of E&O doesn't eat up too much of your earnings.
How is it so "malicious" to want to reduce the cost of warranty service when missing permissions break apps?
I say this after watching a friend working a project he called me into review an issue he was having. He was able to work out where the issue was the problem was he couldn't completely explain to me what the code was expected to do. He then explained that he decided to jump online to find some code that did what he wanted rather than writing it himself to not have to reinvent the wheel. With that being considering I am getting the feeling that many younger programmers who want to save time just look for something that works but don't completely understand what the code is doing.
From my standpoint, unless you 100% understand what you are embedding into your program it shouldn't be there and if you can't explain the code you are using or writing you might be in the wrong field.
Is anyone using a firewall? Can you trust it? Why?
Next week: A discussion on the false dichotomy, and other rhetorical fallacies.
Android is simultaneously extremely accessible, with practically no barrier to entry and few standards for publication, and extremely complex, making it difficult for even experienced developers (or perhaps especially for experienced developers) to write decent apps. The end result is a general lowering of customer expectations, which undermines developers' argument for doing things right as opposed to doing them now.
The article mentions sandbox tools that allow admins to test applications and see what the code and the libraries are really doing, but doesn't name any of them. Any /.ers know if there are FOSS or BSD tools of this sort? Or even cheap proprietary ones? I read the code for any library I use, and I try to add some assert() like statements where the lib dev might have felt them unneeded to be certain that nothing gets past memory boundaries. But everyone misses something now and then, and just look at the IOCCC to spot how code that looks like it does one thing can do something else.
As someone who has written a few apps (none for sale, just local use) I feel like the article was taunting developers, "We know how to tell if you've been duped by your library code, and while we'll bash on developers who don't read the code they use, we won't help out those are writing in a new language and might get tricked by some language specification (or in C's case, unspecified compiler-dependent behavior). We'll even tell you that tools exist, but we won't name even one of them." Sure, I can spend all day trying to guess what type of sandbox tool I'm looking for, and install and test 30 or so of them, but that opens up the same can of worms of trusting code that I haven't read.
Comment removed based on user account deletion
And if obtaining root access trivially is important to an Android user, they will choose their device accordingly.
So how does one who has been given a hand-me-down device, such as my cousin, go about that? Sell the device on Craigslist and buy another?
Nexus devices don't require some exploit to be found to achieve root... it's a very straightforward process.
Root on a Nexus requires unlocking the bootloader, which in turn requires wiping the device. This means you lose all your data if you want to gain root at any time other than the day you buy a new device.
You can buy Linux devices setup as kiosks that lock the user out of root.
The difference is still that GNU/Linux PC owners are expected to have root. All major distros either ask for a root password or put the first created user into a "wheel" group (which has sudo rights) during installation or the first boot. So there is root by default on the "typical" GNU/Linux PC. Reminding the machine's owner to establish and keep root access is the rule, not the exception as it is on Android. Besides, there are plenty of things that don't require root on GNU/Linux but do on Android, such as installing fonts to a single user account.
Let's be honest here: most of the data can be backed up.
I'm aware of that. Say I were to back up my first-generation Nexus 7 tablet through Android Debug Bridge (ADB). How would I verify the completeness of this backup?
GNU/Linux PC owners are expected to have root.
Not on a kiosk, video game console, a TiVo, or any other "appliance".
Which such appliance is a "GNU/Linux PC"? Video game consoles do not run Linux (except for those few remaining fat PlayStation 3 consoles that haven't been upgraded past system software 3.20). TiVo DVRs run Linux but not GNU/Linux. You keep bringing up "kiosks"; to which kiosks are you referring?
Read more from Here
Tutorial and Tips
You're moving the goalposts with this "No true Linux" thing.
I said GNU/Linux in #47550429 precisely to avoid "no true Linux".
if you buy an appliance-type computing device (which I gave multiple examples of already,
I must have missed where you named a make or model of appliance of using GNU/Linux, not a non-GNU userland on the Linux kernel. The point I was trying to get across in #47550429 was that GNU/Linux is less likely than other kinds of Linux-based operating system to come installed on an appliance locked down against its owner.
and smartphones are one)
As the GNU/Linux FAQ explains: "There are complete systems that contain Linux and not GNU; Android is an example. [...] What makes Android different from GNU/Linux is the absence of GNU." I think we're in violent agreement on the concept, just not on the terminology.