Hi, I'm the founder of SourceDNA and I can answer any questions you have. We've built an index of the code in iOS and Android apps, so we can quickly answer detailed questions about how they were built.
In this case, the Android NDK does not include OpenSSL (libssl and libcrypto), so developers have had to come up with their own approach. The correct one is to statically link your native extension with your own copy of OpenSSL or include a dynamic (.so) copy of it in your APK. But some developers were retrieving the library from a random Android device to link against, but then relying on the OS to provide exactly those same symbols.
That assumption failed when Google moved to BoringSSL, Adam Langley's rewrite to improve security. He had to change some APIs and thus break binary compatibility.
The problem is, nobody knew which apps have this problem. They will continue to work fine until run on the newest Android devices with Android M, such as the Galaxy S6, Note 4, and Nexus.
We scanned our index for apps that had native code, matched each app's binaries against libcrypto.so and libssl.so, and built a graph of each dependency linkage. Then we could trace the graph to find apps that had this flaw and exactly which of their libraries was at fault.
If you're a developer, I'm interested in hearing what you think.
Hi Chris, sorry you think that. I see you're a Googler, and actually I first heard about this issue from someone on your Play team. I haven't seen any discussion of it outside an obscure post on Google's Android blog -- have you?
Hey Mike, we had to make a judgement call on this one. We know exactly which ones (there are about 3,000), but it's something you'd probably be sensitive about if you're affected, right?
These aren't bad or minor developers, since using the NDK is often a sign you care about performance of your app or are doing something interesting that's outside the norms of Java.
Are you a user trying to figure out about apps you use or a developer wondering if your own apps have this issue?
I'm really just an observer. The presentation smells far too much of local TV news ads. "This common soda ingredient could kill you! But we won't tell you which one until after sports and the weather!"
I don't really see the problem with letting people search without signing up. This isn't a security vulnerability, right? It's just "these apps will crash on the next OS version." Which anyone can find out for themselves if they get their hands on it and test the apps they're interested in.
I hear you. We also track security flaws in apps and users can see all of their apps' issues. We don't yet have a way to separate which issues you can see.
We're trying to figure out the right balance between allowing anybody to quickly look up an app but not becoming the hammer that end users take to bash developers. A few months ago, we found 25,000 iOS apps with an SSL flaw and allowed anybody to look up which ones. There were a lot of uninformed complaints to developers, even if the app only used the library to load images or some other non-sensitive use.
Suggestions welcome on how to balance this, and we'll keep trying to find the right one.
If it's mixed up with security issues then that is certainly troublesome. I think this is a question of context. My first exposure to your company was with this blog post, and with that it seems like you're trying to gather data to tell people if their apps crash. But really you're focused on security and this is a side benefit, if I understand it correctly.
What about making available a big text file with the names or identifiers of apps affected by this problem? Or if you can whip up a quick search interface (I know, always sounds easier than it is) to just this list of apps, maybe provide that as an alternate.
Your experience with that SSL flaw is interesting. I'm guessing/hoping it wouldn't apply here because the apps really will fail when you say they will, but I see where you'd want to be cautious.
Anyway, thanks for explaining the context and providing this service.
Yeah, we'll see about making a one-off just for searching for this flaw. We add issues to our index constantly, and many are security-related but not this one.
Thanks for the tips, and we'll try to do better next time.
9 comments
[ 2.9 ms ] story [ 34.8 ms ] threadIn this case, the Android NDK does not include OpenSSL (libssl and libcrypto), so developers have had to come up with their own approach. The correct one is to statically link your native extension with your own copy of OpenSSL or include a dynamic (.so) copy of it in your APK. But some developers were retrieving the library from a random Android device to link against, but then relying on the OS to provide exactly those same symbols.
That assumption failed when Google moved to BoringSSL, Adam Langley's rewrite to improve security. He had to change some APIs and thus break binary compatibility.
The problem is, nobody knew which apps have this problem. They will continue to work fine until run on the newest Android devices with Android M, such as the Galaxy S6, Note 4, and Nexus.
We scanned our index for apps that had native code, matched each app's binaries against libcrypto.so and libssl.so, and built a graph of each dependency linkage. Then we could trace the graph to find apps that had this flaw and exactly which of their libraries was at fault.
If you're a developer, I'm interested in hearing what you think.
These aren't bad or minor developers, since using the NDK is often a sign you care about performance of your app or are doing something interesting that's outside the norms of Java.
Are you a user trying to figure out about apps you use or a developer wondering if your own apps have this issue?
I don't really see the problem with letting people search without signing up. This isn't a security vulnerability, right? It's just "these apps will crash on the next OS version." Which anyone can find out for themselves if they get their hands on it and test the apps they're interested in.
We're trying to figure out the right balance between allowing anybody to quickly look up an app but not becoming the hammer that end users take to bash developers. A few months ago, we found 25,000 iOS apps with an SSL flaw and allowed anybody to look up which ones. There were a lot of uninformed complaints to developers, even if the app only used the library to load images or some other non-sensitive use.
Suggestions welcome on how to balance this, and we'll keep trying to find the right one.
What about making available a big text file with the names or identifiers of apps affected by this problem? Or if you can whip up a quick search interface (I know, always sounds easier than it is) to just this list of apps, maybe provide that as an alternate.
Your experience with that SSL flaw is interesting. I'm guessing/hoping it wouldn't apply here because the apps really will fail when you say they will, but I see where you'd want to be cautious.
Anyway, thanks for explaining the context and providing this service.
Thanks for the tips, and we'll try to do better next time.