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."
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.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
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.
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.
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 user experience first. They won't want to inconvenience their users that much.
John
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 be so dumb as to assume that just because it's Apple, it can't possibly have been an engineer making a technical decission.
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.
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.
Nowadays that's more or less the default scenario.
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.
Irony: Agile development has too much intertia to be abandoned now.
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.
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 executable images in the same app bundle and convenience of building app bundles if the libraries are provided as .dylibs.
Neither OS X nor iOS are really set up to manage shared libraries/frameworks as installable objects separate from applications that use them. Perhaps they should be set up to do so, but that might need to be done carefully to avoid, well, DLL hell.
OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks, and there are some applications that do that. There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.
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)
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.)
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 that knowledge wired into it).
And it definitely does not have a way to tie installable application A to installable shared library/framework X, so that installing A automatically installs X if A and X are separate packages from separate vendors.
That is the sort of "[management of] shared libraries/frameworks as installable objects separate from applications that use them" to which I was referring.
And, yes, that does sound a bit like the packaging management systems on some Linux distributions. From my limited experience with various Linux VMs on my Mac, they seems to work OK, but I don't have enough experience with them to say that there aren't problematic failure modes.
At least OS X frameworks have some support for versioning, so that if application A tested with version n of X and set up to require version n and application B is tested with version m of X and set up to require version m, they could be installed "side-by-side".
There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.
And set up a framework (no pun intended) so that they can do the same sort of vetting of frameworks that they do on applications. Yes, that would be a Good Thing, but I'm not about to assume, without further information, that it's not that hard.
It's not even really a library (in the linking sense). It's just a set of source files you add to your project.
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
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 something goes wrong the vendor will fix it and on the other side, the vendor pocket the money and doesn't fund the developers that make him existing in first place or at least the most critical libraries that justify the companies to buy Linux instead of getting it for free and funding directly the projects they believe they critically depend on.
Achille Talon
Hop!
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)
What about every app that does a HTTP gets the wrong content-type? http://stackoverflow.com/quest...
Support Eachother, Copy Dutch Property!
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.
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.
The cesspool just got a check and balance.
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"
The cesspool just got a check and balance.
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.
Do not look at laser with remaining good eye.
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.
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 every single version of the library just in case downloading a new version breaks their app.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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 through all the manifests (or keep a little sqlite db or something) and remove non-core library packages anytime a user deletes the last application which depends on it. Its not 100% easy stuff, but there are plenty of working examples, out there to lift concepts and perhaps even code from.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Great. Bloat your executables to hell. I guess that's why Keynote takes 600M on an iPhone, Word 400~ etc.
Why does it need to be in the title? It's in the summary.
"A plan fiendishly clever in its intricacies"- Homer Simpson
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.
It's a COM issue, and has existed since there was a registry. If you write a COM dll you will still have to deal with DLL hell. The problem hasn't gone away, it's just been replaced with .Net and the global assembly cache. In .Net you can still specify that you want your DLL to register for COM interop - rarely needed to do it, but sometimes you are working on ancient code and it's the only way for it to talk to a .Net dll.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
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.
This sig intentionally left blank.
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
I don't think he was saying it was Apple's fault, just that Apple didn't prevent it. There's a huge distinction. I mean, anyone posting here was alive on 9-11-2001 and none of us prevented it; are you saying we all caused it? I mean, it's true that if we had all done things a little differently, it could have been prevented, right?
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 linking this or any other library, leading to the same problem, but it would have made it much less likely. It is, however, Apple's fault that the current situation was the only option; the headline could have, instead, read "App Developers Not Using Apple's Security Measures, Creating Vulnerable Apps", which would read as a good bit of PR for Apple and bad press for those developers, whereas the current situation has people pointing the finger at both sides.
As far as which is the better technical decision, that's a debate that will continue indefinitely. For marketing purposes[1][2], offering a signed repository of libraries would have protected Apple's interests in this instance, even if it didn't prevent developers from statically linking this library.
[1] And what is Apple, really, if not a marketing firm that just happens to produce some electronic devices?
[2] Don't get me wrong, I quite enjoy my 2 MacBook Pros, iPad, and 3rd gen iPod, but let's not delude ourselves by thinking they're really better than the competition and anything but marketing.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
On one hand yes, the developers should have updated their apps and submitted those updated versions as soon as the library was fixed and each of these apps would have been patched in 4-7 days. On the other hand, if Apple were managing a repository of libraries they could have updated the library in a matter of minutes.
.Net is popular for a reason. Users? We like not having to rely on a developer who may have moved on to another project to eventually get around to fixing their app and we like not having to update our apps in the first place. Platform devs? I'm pretty sure they like being able to point at issues like this and say "my platform doesn't have that problem". So, I guess the answer to that question is nobody doesn't want that.
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 Apple would have gotten some good PR out of this, being able to point at all of the apps using the version in their repository and say "but these apps were all fixed within minutes, with no action from the developers". Who doesn't want that in their platform? Developers? We like not having to match security vulns ourselves;
Bad developers will always make stupid decisions, but that doesn't mean good developers can't offer them better solutions.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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, more secure than the current system.
What if the old version is insecure, and the new version incompatible?
Then you keep using the old version. That, of course, makes that particular app insecure, but your system is, overall, more secure than the current system.
Do you go for insecure-but-working, or broken-but-secure?
Insecure but working. That, of course, makes that particular app insecure, but your system is, overall, more secure than the current system.
What if the developer isn't around anymore to fix it?
Then you run into the same problem we have today. That, of course, makes apps using that particular library insecure, but your system is, overall, more secure than the current system.
Then there's security - if you come up with a way to do this, how do you isolate the data from one another?
The data belongs to the application, not the library. It shouldn't be too difficult to do nothing and let the data continue belonging to the application and not the library.
How do you keep the library (which has access to everyone's data) from accessing and passing around the information?
You don't, you don't need to, and your assumption is incorrect. The library gets linked into the application; it, therefore, has only the application's permissions and can access only what the application can access. The worst case is no worse than what we have today, where a malicious library can access data belonging to the app it is linked into and perform any actions that app can perform; the best case is that libraries with vulnerabilities can be patched and apps that are only compatible with versions of libraries with critical vulnerabilities can be pulled until they have been updated.
Perhaps a malicious update goes and accesses everyone's information then dumps it to another app for uploading?
This is why Apple would manage the repository of libraries (e.g. "You", in all of the examples above, would be Apple). It's also a non-issue, since the library gets linked into the application and, therefore, has only the application's permissions and can access only what the application can access. The worst case is no worse than what we have today, where a malicious library can access data belonging to the app it is linked into and perform any actions that app can perform; the best case is that libraries with vulnerabilities can be patched and apps that are only compatible with versions of libraries with critical vulnerabilities can be pulled until they have been updated.
You'll see that I kept it simple by repeating a lot of my clauses, so you don't have to parse as much in order to understand how wrong you are.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
And great... now a 3rd party can inject code into any application!
Only if Apple signs the updated library.
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.
Is Apple now responsible for all MIT licensed software on GitHub?
The cesspool just got a check and balance.
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?
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.