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."
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.
iOS 2.0 added NSURLConnection. iOS 7 added NSURLSession. Downloading chunks of data and saving them to a file is trivial with the latter, still pretty easy with the former. I'm not sure what you needed to do prior to iOS 2, but that's ancient history - I doubt anyone is still supporting back that far. Point is, using a 3rd party library today when there are straightforward classes to do it in Foundation that have been debugged already by Apple (and will continue to be so) is the only really sensible option. Even if you're writing cross-platform it's easy enough to create equivalent objects you can interface to that wrap other networking solutions on non-iOS devices.
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.
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.