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