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