【问题标题】:How to fix log4j vulnerability - Gradle如何修复 log4j 漏洞 - Gradle
【发布时间】:2022-01-17 13:15:10
【问题描述】:

众所周知,log4j 漏洞已经出现。我们如何才能在我们自己的项目中缩小这一差距?我们有机会在 gradle 上推送一个版本吗?

【问题讨论】:

    标签: android gradle log4j


    【解决方案1】:

    我自己的帮助解决方案

    constraints{
            implementation("org.apache.logging.log4j:log4j-core"){
                version{
                    strictly("[2.15,3[")
                    prefer("2.15.0")
                }
                because("CVE-2021-44228 : Log4j is vulnerable to remote code execution")
            }
        }
    

    【讨论】:

      【解决方案2】:

      这是我们在 spring-boot 项目中使用的解决方案,我们使用 enforcedPlatform 方法管理依赖项:

      dependencies {
        api(enforcedPlatform("org.springframework.boot:spring-boot-dependencies:${springBootVersion}")) {
          exclude(group: "org.apache.logging.log4j")
        }
        api(platform("org.apache.logging.log4j:log4j-bom:2.15.0")) {
          because "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
        }
      }
      

      这是为了在我们能够升级到引入固定版本本身的 Spring Boot 版本之前就位。

      【讨论】:

        【解决方案3】:

        警告:

        截至 2021-12-16 此线程中的其他答案已过时。不要直接使用其他答案。


        更新:2021-12-18...

        请记住始终从下面列出的资源中查看最新信息

        CVE-2021-45105... 2.16.0 和 2.12.2 不再是有效的补救措施!当前的修复版本是 2.17.0 (Java 8) 和 2.12.3 (Java 7)。所有其他 Java 版本都必须采取权宜之计(从 log4j-core JAR 中删除/删除 JndiLookup.class 文件。
        我已相应地在下面更新了我的消息。



        补救措施:
        CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
        虽然大多数需要知道的人可能已经知道足够多的知识来做他们需要做的事情,但我想我还是会把这个放在以防万一......

        • 遵循这些资源中的指导......它可能会改变,但是

        截至 2021 年 12 月 18 日

        基本上是

        • 尽可能删除 log4j-core JAR 文件
          • 从两台正在运行的机器上立即修复和
          • 在您的源代码/源代码管理文件中,以防止未来的构建/发布/部署覆盖更改
        • 如果这不可能(由于依赖),请升级它们
          • 如果你运行的是 Java8,那么你可以升级到 log4j 2.17.0+
          • 如果您运行的是早期版本的 Java,则可以升级到 log4j 2.12.3
          • 如果您运行的是旧版本的 Java,则需要升级到最新版本的 Java,然后使用最新版本的 Log4J
          • 同样,这些更改必须同时发生在正在运行的机器和代码中
        • 如果由于某种原因这两种方法都不可能……那么从 log4j-core JAR 中删除 JndiLookup.class 文件是非补救性的。
          • 在 Linux 上使用zip 命令提供了一种止损选项,默认情况下,大多数 Linux 发行版都附带该命令。
            • zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
          • 在撰写本文时,大多数 Windows 上的止损选项在线指南都说要执行以下操作(再次...假设您无法执行上述删除 JAR 或升级选项之一):
            • 安装类似 7-zip 的东西
            • 找到所有 log4j-core JAR 文件,并为每个文件执行以下操作...
            • 重命名 JAR 以将扩展名更改为 .zip
            • 使用 7-zip 解压缩 JAR(现在有一个 .zip 扩展名)
            • 从解压缩的文件夹中找到并删除 JndiLookup.class 文件
              • 路径是\\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
            • 删除旧的 JAR 文件(现在扩展名为 .zip)
            • 使用 7-zip 重新压缩文件夹
            • 重命名新的 .zip 文件夹以将扩展名更改为 .jar
          • 还有一些使用 Power Shell 的选项

        如果您只有 1 或 2 个 JAR 文件要处理并且您不介意安装 7-zip 或者您有 PowerShell 可用,这很好。但是,如果您有很多 JAR 文件,或者您不想安装 7-zip 并且无权访问 Power Shell,我创建了一个开源 VBS 脚本,无需安装即可为您执行此操作任何附加软件。 https://github.com/CrazyKidJack/Windowslog4jClassRemover

        阅读自述文件和发行说明https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

        【讨论】:

        • 请务必注意,只有 log4j-core JAR 易受攻击。所以你也许可以从你的项目中省略它,而仍然使用其他 log4j 库(如 log4j-api)
        猜你喜欢
        • 2022-01-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2022-01-20
        • 2021-08-14
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多