我正在研究一个大型遗留项目，并尝试解决OpenSSL漏洞问题，如How to address OpenSSL vulnerabilities in your apps所述。
问题是，有很多依赖项，有些是开源的（我更新了所有没有破坏兼容性的），作为Gradle导入添加，有些是由我工作的公司的合作伙伴和承包商提供的自定义/封闭源作为JARs并作为项目附属于该项目。
有没有办法确定具有此漏洞的特定库？我使用了Google Play and OpenSSL warning message提供的bash脚本，它指向一个本机依赖项（实际上是.so文件）。有没有选择来确定那里的实际依赖？
答案 0 :(得分：2)
有没有选项来确定那里的实际依赖？
是的，但您需要了解违规的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库将其版本作为字符串嵌入数据部分。最终，您将遇到罪魁祸首，这可能是预先构建为共享对象但包含OpenSSL作为静态库的SDK。一个SDK似乎经常被识别，它使用针对静态OpenSSL库构建的cURL。
如果您有JAR files and suspect them，那么您可以执行以下快速测试：
find <dir> -name '*.jar' -exec grep -R '1.0.1h' {} \;
该命令将在目录<dir>及其子目录中查找。它将搜索*.jar扩展名的文件。当找到一个时，它会在其上运行grep寻找字符串。 find会为找到的每个*.jar执行此操作。