dawkins83 dawkins83 - 9 months ago 82
Android Question

How to determine which dependency causes Google Play OpenSSL warning?

I'm currently working on a big legacy project and trying to fix the OpenSSL vulnerability issue as explained at How to address OpenSSL vulnerabilities in your apps.

The problem is, there are lot of dependencies, some are open source (I updated all that didn't break the compatibility) added as Gradle import, some are custom/closed source provided by partners and contractors of the company I work for and attached to the project as JARs.

Is there any way to pinpoint specific library that has this vulnerability? I used the bash script provided at Google Play and OpenSSL warning message and it points to one native dependency (actually the .so file). Is there any option to pinpoint actual dependency from there?

jww jww

Is there any option to pinpoint actual dependency from there?

Yes, but you need to know the offending OpenSSL version and you need grep. Windows find won't do.

First, take note of the offending OpenSSL version. For sake of argument, say its due to OpenSSL 1.0.1h.

Next, gather a list of your dependencies and their top level folders. For sake of argument, say its $HOME/Desktop/aosp-app, $HOME/sdk-a, /usr/local/sdk-b and /opt/local/sdk-c.

Finally, for the top level directories:

grep -R '1.0.1h' "$HOME/Desktop/aosp-app"
grep -R '1.0.1h' "$HOME/sdk-a"
grep -R '1.0.1h' /usr/local/sdk-b
grep -R '1.0.1h' /opt/local/sdk-c

You don't need grep -iR, which is a case insensitive (-i) recursive (-R) search. You also don't need grep -IR, which is a recursive (-R) search that skips binary files (-I).

All of this works because OpenSSL library embeds its version in the data section as a string. Eventually, you will hit on the culprit, which is probably an SDK that comes pre-built as a shared object but includes OpenSSL as a static library. One SDK seems to be identified frequently, and it uses cURL which is built against a static OpenSSL library.