I think I have a good idea of what you're suggesting to do; but I'm clear on the best way to implement this solution. (I have a few other questions in general; which I will save for the end of the post). Could you post sample, or more step - by - step instructions for using the sed --binary command?
So to clarify; this is my understanding of what I should be doing. 1) The strategy is to use the sed command to replace any binaries with vulnerable versions of OpenSSL to either --> - 1.0.1h, - 1.0.0m, - 0.9.8za 2) The sed commands will recursively search through all the strings in the binary files within the application and the aar, jar & JNI linked native libraries and replace the OpenSSL .so native libs; inside the binaries themselves. This will include statically & dynamically linked libraries dependencies. Here are my questions about implementing this strategy 1) Should I be running the sed command on the final unzipped .apk file? If so, should I build the .apk without minify, zipalign & proguard so that the sed command will work properly? Should I be using dex2jar? 2) Can I run the sed command after building the project, but before compiling the .apk; by running it on the project build folder? 3) Is there a tool to list binaries & dependencies in a project? My problem with the grep command is that it gives you no hints as to where and whom the dependencies belong too. The same for the script in the aforementioned stack overflow post. I found where the offending packages where being used via import & class loading statements, using dex2jar and searching on the jar of the project. What if there are other binaries that are linking to the offending libraries outside of the Java layer? Is there a similar tool to search in native code? 4) Could this be done with a gradle task? IE. after evaluating, search for and .so file extensions and replace them with the corresponding updating version. If so, do you have any ideas where I could look to build this? I think the gradle solution could have advantages over the sed command b/c you can replace the binaries before the project is built, instead of replacing it afterwards. If the binaries is incompatible; hopefully the IDE will pick it up at compile time. 5) Final question, you mentioned before that the vulnerable versions could be being supplied by the IDE; I don't understand what you meant by that. Did you mean that there could be an old version in your maven repo; and that the repo should be refreshed. (I did try that and it didn't work; but I'm thinking that could still be part of the problem, no?) Thank you, David On Monday, September 28, 2015 at 7:01:54 PM UTC-4, Jeffrey Walton wrote: > > On Mon, Sep 28, 2015 at 6:40 PM, Spark85 <[email protected] > <javascript:>> wrote: > > Hi Jeff, > > > > Thank you for the quick response. I'm not sure I follow what you are > > suggesting I do. > > > > I looked at the source for the classes with OpenSSL, here is what I > found. > > Not the sources. If you were building OpenSSL from sources, you would > just use OpenSSL 1.2d. > > > ... > > Are you suggesting replacing the qualified name for the SSL libraries to > a > > save version? If so, what should I be doing to test that it doesn't > break > > my code? > > No, I'm saying to edit the actual binary provided by whomever. Your > IDE or one of the SDK's you are using is providing a down level > version of the openssl libraries. > > You need to identity the name of it because they (the vendor) have to > wrap the openssl static libraries (libcrypto.a and libssl.a). They > have to wrap it in a shared obect for JNI. > > If they (the vendor) try to provide the the actual libcypto.so or > libssl.so, then you will link to it at compile time. However, at > runtime, you will get Zygote's copy of openssl. The link/loader won't > load your updated shared objects from the APK because the dependencies > "libcrypto.so" and "libssl.so" and the symbols they provide are > already satisfied. > > Once you identify the shared object (just use `strings`), then you can > use a stream editor in binary mode to change the OpenSSL version in > the compiled binary. > > For example, see below. Those are the strings you have to change. Hit > it with `sed --binary`. "OpenSSL 1.0.2d 9 Jul 2015" is a long string, > and it likely won't collide with, for example, processor instructions. > > But like I said, because of Zygote, its *not* going to be named > "libcrypto.so". > > Jeff > > $ strings /usr/local/ssl/android-18/lib/libcrypto.so | egrep > "([0-1]\.[0-1]\.[0-2])" > libcrypto.so.1.0.0 > OpenSSL 1.0.2d 9 Jul 2015 > MD4 part of OpenSSL 1.0.2d 9 Jul 2015 > MD5 part of OpenSSL 1.0.2d 9 Jul 2015 > SHA part of OpenSSL 1.0.2d 9 Jul 2015 > SHA1 part of OpenSSL 1.0.2d 9 Jul 2015 > SHA-256 part of OpenSSL 1.0.2d 9 Jul 2015 > SHA-512 part of OpenSSL 1.0.2d 9 Jul 2015 > RIPE-MD160 part of OpenSSL 1.0.2d 9 Jul 2015 > DES part of OpenSSL 1.0.2d 9 Jul 2015 > libdes part of OpenSSL 1.0.2d 9 Jul 2015 > !"#$% > !"#$%&'()*+,-./0123456789:;<=>?@ABCD./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzAES > > > part of OpenSSL 1.0.2d 9 Jul 2015 > RC2 part of OpenSSL 1.0.2d 9 Jul 2015 > RC4 part of OpenSSL 1.0.2d 9 Jul 2015 > IDEA part of OpenSSL 1.0.2d 9 Jul 2015 > :Blowfish part of OpenSSL 1.0.2d 9 Jul 2015 > \CAST part of OpenSSL 1.0.2d 9 Jul 2015 > OCAMELLIA part of OpenSSL 1.0.2d 9 Jul 2015 > Big Number part of OpenSSL 1.0.2d 9 Jul 2015 > (1RSA part of OpenSSL 1.0.2d 9 Jul 2015 > DSA part of OpenSSL 1.0.2d 9 Jul 2015 > ECDSA part of OpenSSL 1.0.2d 9 Jul 2015 > Diffie-Hellman part of OpenSSL 1.0.2d 9 Jul 2015 > ECDH part of OpenSSL 1.0.2d 9 Jul 2015 > Stack part of OpenSSL 1.0.2d 9 Jul 2015 > lhash part of OpenSSL 1.0.2d 9 Jul 2015 > RAND part of OpenSSL 1.0.2d 9 Jul 2015 > EVP part of OpenSSL 1.0.2d 9 Jul 2015 > ASN.1 part of OpenSSL 1.0.2d 9 Jul 2015 > PEM part of OpenSSL 1.0.2d 9 Jul 2015 > X.509 part of OpenSSL 1.0.2d 9 Jul 2015 > CONF part of OpenSSL 1.0.2d 9 Jul 2015 > CONF_def part of OpenSSL 1.0.2d 9 Jul 2015 > TXT_DB part of OpenSSL 1.0.2d 9 Jul 2015 > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
