Networking Library Bug Breaks HTTPS In ~1,500 iOS Apps 73
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."
Re: (Score:3)
Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
Re: (Score:1)
Alternatively, it's a security decision, because they don't want one 3rd party to be able to inject code into another 3rd party application except under very controlled circumstances (which would be why iOS 8 supports dynamic libraries, but heavily restricts exactly the circumstances in which one can be used).
Or... It could be a performance issue. Not doing a bunch of dynamic linking at application launch time would get applications launching much faster on resource constrained devices.
Or ...
That is, don't
Re: (Score:2, Insightful)
Alternatively, it's a security decision
That has now been proved was a bad decision.
Absolutely false - it has proven that 1500 apps made a poor 3rd party library decision.
No-one is claiming that. What people are saying is that the decision was bad. The accusation isn't that Apple doesn't engineer stuff, the accusation is that it is badly engineered.
Or, it could be that some people were lazy and decided to use a crappy library? If you choose to use security by obscurity library 'x', is it Apple's fault when that security hole is discovered in your App? What Apple should do is remove all ~1500 apps from the App Store as being "unsuitable" for sale. They've done it with others for far less serious issues.
Re: (Score:2)
Or, it could be that some people were lazy and decided to use a crappy library? If you choose to use security by obscurity library 'x', is it Apple's fault when that security hole is discovered in your App?
AFNetworking is MIT-licensed, FYI. You can look it up on Github.
Re: (Score:1)
Re: (Score:3)
It's done the way it is because the alternative is unmanageable.
Apple would have to introduce a way for app developers to add external dependencies to their executables and for those external dependencies to be downloaded, if necessary, along with the app. This is obviously all possible as the Linux and BSD package management systems demonstrate but it would mean Apple would have to maintain an enormous repository of external libraries and the app developers would have to regression test their apps against
Re: (Score:1)
Just going to point out something you just said. Linux and BSD do it. So Apple can't why?
Because they want a system that people can and will use. You know, unlike Linux and BSD.
Re:Poor Design... (Score:5, Insightful)
Before you lambast Apple for poor engineering decisions, think carefully about the ramifications of using shared third-party libraries. DLLs have their own problems - hence the well known term "DLL Hell".
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.
Optimal Default Conditions (Score:1)
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
Re: (Score:1)
You are reaching ridiculous levels to try and justify your belief that somehow this is all Apple's fault and that they should have engineered their system better.
This is the App author's responsibility, nobody else's. They took a decision to use a third party library rather than use whatever tools or libraries Apple provides. It is, however, easy for them to do the update - simply link against the new library and re-publish to the app store.
Re: (Score:2)
The fact is that Apple could have implemented a system that would have at least made this an avoidable situation. Of course, it wouldn't have stopped developers from statically
Re: (Score:2, Insightful)
Not at all; a developer is making a decision to trust a third-party when he incorporates the third-party library into his app.
And there's your answer - it's the developer's decision, much like if they wrote their own crappy code. It's not Apple's problem. The true headline should be "Companies X, Y, Z produced insecure apps - don't use these"
Re: (Score:2)
Before you lambast Apple for poor engineering decisions, think carefully about the ramifications of using shared third-party libraries. DLLs have their own problems - hence the well known term "DLL Hell".
Uh, yeah, that was an issue for Windows 3.1 more than twenty years ago. There have been a few advances in dealing with this since then. Using Windows 3.1 engineering issues as an excuse for current bad engineering issues doesn't really cut it.
Re: (Score:3)
if by advances you mean 10+ gigabyte WINSxS directories that make the OS suck balls to run visualize / backup unless you have an expensive block level de-dupe system on SAN than yes there have been advances.
Re: (Score:2)
Re: (Score:3)
Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
It saves them money; they don't have to spend the time developing a robust system for DLL registration, signing, updating, etc...
But it is still a really bad engineering decision, because it means what could have been patched once has to push security updates in *fifteen hundred statically linked applications*. It's their marketplace and their walled garden; they should be subsidizing the expenses which make it more secure for everybody and reduce total developer time for publishers. Push the update to developers a little in advance in case it breaks an app, then auto-push the update either to everyone or with a held-back copy for any apps that specifically flag no-security-update.
It's not rocket science, it's just good engineering.
So what are you suggesting? That every single library every single third party app uses all be installed into one location? And that every single application submitted to the app store break out their libraries separately?
iOS apps are meant to be completely contained within a single bundle.
(and yes, iOS supports dynamically linked libraries, of course it does)
Re: (Score:2)
The sensible way would be to do what every Linux distro has been doing for 20 years now. The "APP" includes a manifest of its dependencies. When you install it from the App store (remember Apple does not make side loads easy, unless you are developer in which case you can solve deps issue by having the required packages available) it simply goes an fetches the required libraries at the same time if you don't already have them.
This is a solved problem!
Taking in one tiny step further IOS just needs to scan
Re: (Score:2)
And great... now a 3rd party can inject code into any application!
Only if Apple signs the updated library.
Re: (Score:2)
The sensible way would be to do what every Linux distro has been doing for 20 years now. The "APP" includes a manifest of its dependencies. When you install it from the App store (remember Apple does not make side loads easy, unless you are developer in which case you can solve deps issue by having the required packages available) it simply goes an fetches the required libraries at the same time if you don't already have them.
So then every developer would have to submit all the libraries they use separately so that they can be indexed and maintained? Who signs the libraries? How do they know Library A doesn't have a backdoor from Developer B when used in App C?
Re:Poor Design... (Score:5, Insightful)
It's not apple's fault, it's 1500 bad developers that did not instantly compile with the updated library and submit for update to the store.
100% of the blame sits at the feet of the developers of those apps.
Re: (Score:2)
Sure, developers might have stupidly decided to statically link the library in their app despite it being available in Apples repository, and those apps would still have the same issue, but
Re:Poor Design... (Score:5, Insightful)
Well, to properly do this, requires a way to manage libraries separately from apps. And that rapidly becomes a usability nightmare, as well as, ironically, a security nightmare.
What happens when an update comes out? Do you keep both versions? What happens if an app is incompatible with the new version? What if the old version is insecure, and the new version incompatible? Do you go for insecure-but-working, or broken-but-secure? What if the developer isn't around anymore to fix it?
Then there's security - if you come up with a way to do this, how do you isolate the data from one another? How do you keep the library (which has access to everyone's data) from accessing and passing around the information? Perhaps a malicious update goes and accesses everyone's information then dumps it to another app for uploading?
Effectively, the only way is to statically link the library into each app - this way each app contains a library that works and is tested. But it also means developers are responsible for maintaining their apps.
Re: (Score:1)
Well, to properly do this, requires a way to manage libraries separately from apps. And that rapidly becomes a usability nightmare, as well as, ironically, a security nightmare.
What happens when an update comes out? Do you keep both versions? What happens if an app is incompatible with the new version? What if the old version is insecure, and the new version incompatible? Do you go for insecure-but-working, or broken-but-secure? What if the developer isn't around anymore to fix it?
Then there's security - if you come up with a way to do this, how do you isolate the data from one another? How do you keep the library (which has access to everyone's data) from accessing and passing around the information? Perhaps a malicious update goes and accesses everyone's information then dumps it to another app for uploading?
Effectively, the only way is to statically link the library into each app - this way each app contains a library that works and is tested. But it also means developers are responsible for maintaining their apps.
All great questions, but static linking isn't an answer, it's giving up on having an answer.
Re: (Score:2)
What if the developer isn't around anymore to fix it?
It means you have picked the wrong library since there isn't enough interest in it to sustain it. You should then drop it for a replacement or write your own code. I know, there is plenty of examples of good libraries that are not well funded, so they went unsecure since developers cannot dedicate time to maintain them properly, one recent example comes to mind: OpenSSL and Heartbleed bug. On one side you have all these companies buying expensive Linux distros from respectable vendors with the guarantee if
Re: (Score:2)
What happens when an update comes out?
You build it and add it to the repository.
Do you keep both versions?
Yes, you keep both in the repository. Some app might only be compatible with that version. That, of course, makes that particular app insecure, but your system is, overall, more secure than the current system. Of course, you only keep the libraries specified in the manifests of installed apps locally; there is no need to keep unused versions locally.
What happens if an app is incompatible with the new version?
Then you keep using the old version. That, of course, makes that particular app insecure, but your system is, overall,
Re: (Score:2)
Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
Managing shared libraries across applications works fine in a GNU distribution where the distribution takes responsibility for all applications. With Apple's approach there's no good way to manage this, different applications might use their own specialized version of the library. At most you might have an opt-in system where developers can register the libraries they are using and the version they require, and have the system download and manage them for them.
Re: (Score:3)
Non system libraries are statically linked .a files in IOS. Apple insists on this, although I'm not entirely sure why. I guess its to avoid DLL hell.
I suppose they could support providing dynamically-linked libraries as part of an app bundle. However, it's not clear why that would be any better than statically linking the library, as Apple probably wouldn't allow those dynamically-linked libraries to be shared between applications (apps being sandboxed, they couldn't pull in a .dylib from another app bundle) and wouldn't allow them to be updated separately from the app bundle. The only advantages it might provide would be code sharing between executab
Re: (Score:2)
Re: (Score:2)
OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks,
...and OS X keeps track of which installed applications use them, and either prevent uninstallation of shared libraries/frameworks that are used by installed applications or at least warn about it?
No, it doesn't - it doesn't even have an official uninstaller (although the ambitious can whip up a script to do that, such as the Wireshark uninstaller script I have; not sophisticated, though, as it doesn't dump the file list from the package manifest to figure out what stuff needs to be removed, it just has th
Re: (Score:2)
Great. Bloat your executables to hell. I guess that's why Keynote takes 600M on an iPhone, Word 400~ etc.
Re: (Score:2)
This is where the world is going with per-application library installations on Windows, things like Docker on Linux and application bundles containing libraries/frameworks on OSX. It guarantees that you don't get unexpected application breakage on a library update, but in means a library update requires work for every application using it.
Re: (Score:3)
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?
Maybe because it's not a library or a framework? AFNetworking is a set of classes/source code that you add to your project. It is not meant to be used as a separate library.
And yes, bug fixes always change behaviour
Re: (Score:2)
My apps, which use AFNetworking, are not vulnerable. Precisely because I avoided 2.5.1 because I saw that commit go by and didn't like the look of it.
Re: (Score:2)
It's not even really a library (in the linking sense). It's just a set of source files you add to your project.
Re:Statistics (Score:5, Interesting)
So approximately 0% or 0 apps have upgraded to the fixed code. Maybe instead of blaming those thousand developers, there's another reason?
Indeed there is. You must've glossed over it in the article, since the article makes it clear that the survey was conducted on the same day that the patch was announced, which means that developers hadn't yet had a chance to incorporate the patch, let alone submit an update to the app store. That's why 0% registered as being updated.
[...] 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 developers can already mark critical updates as being in need of an expedited review. Unless the expedited review process is taking too long—and there's no evidence as yet that this is the case (see above for why 0% isn't alarming)—then we're inventing a problem where one does not exist. Note how the article provides users with the ability to poll more recent data, yet they don't present any of that data. The conclusion we might reach is that the results of the later surveys were less than newsworthy, so they've chosen to selectively report on the parts that make for headlines.
Re: (Score:2)
They could maintain a list of third party library versions and identify versions of apps that link with them. But then what? As a user, I might not want Apple to shut off some random app I depend on -- just because they think it might be hackable doesn't mean my device is actually being hacked; and I might really need that app today for some important client presentation.
They could contact impacted developers and request they repair the damage, but what can they do if nobody responds?
Apple focuses on end us
Remove the app (Score:2)
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.
~1500 App Developers wasted their time (Score:4, Informative)
Re: (Score:1)
I don't know why you would say that it's good. Especially early in IOS history it was pretty annoying to write basic networking functionality like downloading and saving a file that's too large to keep in memory. The whole reason people used libraries like these is because Apples API weren't easy enough to use.
Re:~1500 App Developers wasted their time (Score:5, Insightful)
Re: (Score:2)
I think we are actually on the same page, I also never used networking libraries, but I can't blame people that did. NSURLConnection really was lacking.
Yeah, it was all possible, but when you searched for IOS networking problems on sites like Stackoverflow for networking related issues, you would often get answers that just gave a couple of lines of AFNetworking code to fix something that was a PITA in NSURLConnection.
If NSURLConnection really was that good, people wouldn't have bothered with libraries for
Re: (Score:2)
Re: (Score:2)
... and anything from iPhone 4 upwards can use iOS 7. There is practically no reason not to write for IOS 7 exclusively, since nobody with iOS 6 is going to buy any apps anymore.
As of February of this year, all new app releases MUST target iOS 7 or higher as well as support 64 bit
iPod touch 4 doesn't have enough RAM for iOS 7 (Score:2)
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.
Re: (Score:2)
You did nothing. You couldn't write apps for iPhone OS 1.x because iPhone OS 2.0 introduced the app store. So unless you jailbroke, you only wrote apps against iPhone OS 2.0.
Re: (Score:3)
Not for doing anything even the slightest bit complex. Like, for example, certificate pinning and certificate validation, which is what AFNetworking fucked up.
Do you think Apple is better? The APIs are shit. They are horribly documented. They don't "just work" with the high level Objective C APIs, but require a lot of low-level tinkering. They don't perform revocation checks consistently [stackoverflow.com].
People use AFNetworking
Re: (Score:2)
Re: (Score:2)
I'm sorry... were you under the impression that people have ever claimed that open-source means you can't get any bugs in it?
Then you're an idiot.
But don't let us stop you spreading your misinformation based on a complete misinterpretation of other people's statements about open-source code.
(P.S. You can't stop bugs in any code. But if this was a closed-source library, probably the only people who would ever know about it, see the buglist, would be able to fix it etc, would be the people who wrote it.)
Re: (Score:2)
Why does it need to be in the title? It's in the summary.
Re: (Score:3)
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.
Re: (Score:2)
For reference, I'm not the AC you were replying to. I can tell, however, that the target of t
And you thought 1500 apps is bad? (Score:2)
Find those 1500 apps (Score:2)
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?