如何确定哪些依赖性会导致Google Play OpenSSL警告？ [英] How to determine which dependency causes Google Play OpenSSL warning?

问题描述

我目前正在处理一个大型的遗留项目，并试图解决OpenSSL漏洞问题，正如如何解决你应用程序中的OpenSSL漏洞。

问题是，有很多依赖关系，有些是开源的（我更新了所有那些不打破兼容性），作为Gradle导入添加，有些是由我工作的公司的合作伙伴和承包商提供的定制/封闭源代码，并作为JAR附加到项目中。

有什么方法可以查明具有此漏洞的特定库吗？我使用了 Google Play和OpenSSL警告消息中提供的bash脚本，它指向一个本地依赖项（实际上是.so文件）。是否有任何选项可以查明实​​际的依赖关系？

解决方案

是否有任何选项可以查明实​​际依赖关系？

是的，但您需要知道违规的OpenSSL版本，并且您需要 grep 。 Windows find 不会这样。

首先，注意违规的OpenSSL版本。为了争论，可以说它是由于 OpenSSL 1.0.1h 。

接下来，收集您的依赖关系及其顶级文件夹的列表。为了争辩，请说它的 $ HOME / Desktop / aosp-app ， $ HOME / sdk-a ， / usr / local / sdk-b 和 / opt / local / sdk-c 。

最后，对于顶层目录：

  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 
  

不需要 grep -iR ，这是不区分大小写的（ -i ）递归（ -R ）搜索。您也不需要 grep -IR ，这是一个递归（ -R ）搜索，跳过二进制文件 -I ）。

所有这些都是可行的，因为OpenSSL库将其版本作为字符串嵌入数据部分。最终，你会遇到罪魁祸首，这可能是一个作为共享对象预先构建的SDK，但包含OpenSSL作为静态库。一个SDK似乎经常被识别出来，它使用的cURL是针对一个静态的OpenSSL库而构建的。

---

如果你有 JAR文件并怀疑它们，那么您可以执行以下操作作为快速测试：

  find< dir> -name'* .jar'-exec grep -R'1.0.1h'{} \; 
  

该命令将在目录< dir> 及其子目录。它将搜索带有 *。jar 扩展名的文件。当它找到一个时，它会运行 grep 来寻找字符串。 find 会为每个 *。jar 找到它。

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?

解决方案

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.

---

If you have JAR files and suspect them, then you can perform the following as a quick test:

find <dir> -name '*.jar' -exec grep -R '1.0.1h' {} \;

The command will look in the directory <dir> and its subdirectories. It will search for files with the *.jar extension. When it finds one, it will run grep on it looking for the string. find will do it for every *.jar it finds.

这篇关于如何确定哪些依赖性会导致Google Play OpenSSL警告？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！