Slashdot Mirror
Networking Library Bug Breaks HTTPS In ~1,500 iOS Apps
mrflash818 writes: A new report from analytics service SourceDNA found that roughly 1,500 iOS apps (with about 2 million total installs) contain a vulnerability that cripples HTTPS and makes man-in-the-middle attacks against those apps easy to pull off. "The weakness is the result of a bug in an older version of the AFNetworking, an open-source code library that allows developers to drop networking capabilities into their apps. Although AFNetworking maintainers fixed the flaw three weeks ago with the release of version 2.5.2, at least 1,500 iOS apps remain vulnerable because they still use version 2.5.1. That version became available in January and introduced the HTTPS-crippling flaw."
The fact that a library cannot be updated simultaneously with a security patch in all apps in the app store with a change that does not change API or in-app behavior is kind of absurd.
Disclaimer: I am guessing this is the case, or else why would 1500 apps still be vulnerable?
This isn't an iOS bug as the summary implies. It's a bug in AFNetworking - a 3rd party library.
The article says about 1000 apps have the flawed code (not 1500 as mentioned twice in the summary. The summary also makes it sound like these 1000 apps' developers are lazy bastards for not patching already, but the article points out that, of the 20000 apps they found using the library, 55% or about 11000 had never bothered to upgrade to the buggy version. Another 40% or 8000 use the bad version but don't use the code containing the flaw. Only 5% or 1000 apps use the bad code. So approximately 0% or 0 apps have upgraded to the fixed code. Maybe instead of blaming those thousand developers, there's another reason?
While it takes Apple more than a week to approve an app on average, we have no information as to how long they are taking to approve apps that are trying to fix this bug. In other words, all 1000 apps' developers might have upgraded their code 3.4 seconds after the patch released, and still they'd have the flawed code in the version available in the app store.
So let's refocus the discussion, and instead of talking about the pointless stuff in the summary, let's talk about what Apple needs to do to have a faster approval process for apps containing critical bug fixes. Any thoughts?
iOS has perfectly functional networking libraries and simple objects that provide an API to them. Why anyone would bother linking in a 3rd party library to replicate that functionality I can't understand. If a vulnerability were found in the iOS libraries, Apple could roll out an update and fix it overnight. As it is, that's ~1500 apps need to be revved.
They're the ones who created this situation in the first place.
Every year we're seeing new devices with new screen sizes and new versions of iOS that require things to be built slightly differently then before, targeting a new SDK that inevitably requires source level changes to be fully compatible with. At the same time, they're constantly outdating the former SDKs and versions of Xcode in an attempt to force developers to upgrade their apps, because if they don't- then the users start complaining about the black bars on their screen because the app isn't optimized for whatever whacky resolution Apple decided to go with this year.
The net result of all of this is that it costs a phenomenal amount of time and money to continue supporting iOS applications on the app store. You can't just submit something and keep it up to date, supporting whatever versions of the hardware you originally ran on and running in a compatibility layer on anything newer- eventually Apple will force you to upgrade your app to support everything new again. Since Apple won't remove an older app from the app store (unless it's flat out crashing or refusing to work at all), most developers opt to simply "abandon" their iOS apps instead, leaving them up on the store in the state that they were before Apple told them that they'd have to overhaul the entire thing just to submit a minor update.
So it's partially the developers fault for being lazy and using AFNetworking in the first place, but it's more Apple's fault for making it so damned difficult (if not impossible) to submit a minor update without being sucked into redoing everything under a new version of Xcode instead.
Lets not let people know it is an OPEN SOURCE Library, shall we.
Oh, Noes! My Apple is far safer than anything. Steve told me so.
What's funny is that Fandroids are so hostile to everybody else that right now Google is running ads showing animals getting along with other animals. It's hard to take you seriously when your own overlord is telling you to reign it in.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Does Apple have to sign and push the 3rd party shared library itself? That would be the only safe solution I can think of, because otherwise you're giving apps the ability to modify each others' code, which is clearly a recipe for potential abuse. Apple can't realistically take the responsibility for monitoring, compiling, and pushing updates for third-party libraries, which would be nearly impossible to do in practice. Alternatively, there's no way Apple could allow the apps themselves to update the shared libraries, because then a single app could break or even hack thousands of other apps with a bad update. Delegating that authority to a third-party (like the library developer) is equally problematic, because there's no way for them to properly test any changes before pushing them, and the potential for abuse still exists.
DLLs make a lot of sense for shared systems libraries, but as far as third-party libraries, they'd be a practical nightmare.
Not at all; a developer is making a decision to trust a third-party when he incorporates the third-party library into his app. So long as you allow a developer to flag his app as needing to rely on an older version, the benefits would significantly outweigh the risks. Notably, even *IF* one party were to use a library to hack all those apps, you could still fix it in one place rather than having a vulnerability in every app for a year.
You would have to make strict standards for what behavior libraries can change to fall under this shared model, to minimize the likelihood of breaking any programs, but it's a LOT better to default to "secure even though 1 in 100 apps that both needs an old library and has a developer who failed to flag it as needing an old library has problems until fixed" than it is to "1500 apps insecure, with no timetable for securing."
What about every app that does a HTTP gets the wrong content-type? http://stackoverflow.com/quest...
Support Eachother, Copy Dutch Property!
Is there a way that I can download en masse apps on the app store to find which libraries they contain and perform other analysis of them?
-- I was raised on the command line, bitch
Oh, I get along with Apple users just fine. I am one, along with my wife, my best friend, and his wife. I'm the only one out of the group who uses an Android phone, but I'm very happy with both of my MacBook Pros, my iPad, and my iPod. What I can't stand, and I feel this may be the case for most Android users, is the type of idiot who fully buys into the "Apple made it so it's perfectly secure" marketing bullshit.
For reference, I'm not the AC you were replying to. I can tell, however, that the target of their attack is precisely the type of idiot I mentioned, and not the intelligent Apple users who realize that anything can be made vulnerable; the question is, which are there more of? It's hard to say, since the idiots are so vocal.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
In other words, all 1000 apps' developers might have upgraded their code 3.4 seconds after the patch released, and still they'd have the flawed code in the version available in the app store.
A responsible developer would accept responsibility, remove the vulnerable version of the app entirely from the App Store, and accept making zero sales until Apple finishes reviewing the new version.
anything from iPhone 4 upwards can use iOS 7
Except for the iPod touch 4, which doesn't have enough RAM to run iOS 7.