【问题标题】:Log4j vulnerability - Is Log4j 1.2.17 vulnerable (was unable to find any JNDI code in source)?Log4j 漏洞 - Log4j 1.2.17 是否存在漏洞(无法在源代码中找到任何 JNDI 代码)?
【发布时间】:2022-01-15 12:40:06
【问题描述】:

关于Log4jJNDI远程代码执行漏洞CVE-2021-44228-(另见参考资料)-我想知道Log4j-v1.2是否也受到影响,但我从源代码审查中得到的最接近的是JMS-Appender

问题是,虽然网上的帖子表明 Log4j 1.2 也存在漏洞,但我找不到它的相关源代码。

我是否遗漏了其他人已经发现的东西?

Log4j 1.2 似乎在socket-server 类中存在漏洞,但我的理解是,首先需要启用它才能使其适用,因此与 JNDI 查找漏洞不同,它不是被动威胁,后者被识别的那个似乎是。

我的理解 - Log4j v1.2 - 不会受到 jndi-remote-code 执行错误的影响正确吗?

参考文献

这个blog post from Cloudflare 也表示与AKX 相同的点......它是从Log4j 2 引入的!

更新 #1 - (现已停用)apache-log4j-1.2.x 的一个分支,带有针对旧库中发现的几个漏洞的补丁修复程序现已可用(来自 log4j 原作者)。该网站是https://reload4j.qos.ch/。截至 2022 年 1 月 21 日,版本 1.2.18.2 已发布。迄今为止解决的漏洞包括与JMSAppenderSocketServerChainsaw 漏洞有关的漏洞。请注意,我只是在转发此信息。尚未验证我的修复。请参阅链接了解更多详情。

【问题讨论】:

标签: java security log4j log4j2 exploit


【解决方案1】:

JNDI 功能was added into Log4j 2.0-beta9

Log4j 1.x 因此没有易受攻击的代码。

【讨论】:

  • 原来 log4j 1 在某些配置中可能存在漏洞:github.com/apache/logging-log4j2/pull/…
  • 为了进一步增加混淆,RHEL 现在声明他们的一些产品使用 1.2 的实现,这很容易受到攻击。在接下来的几周内(来自好的和坏的参与者)将对该漏洞进行大量研究,以识别所使用机制的变化。如果此时可能的话,升级到 2.15 是最安全的。 RHEL CVE-2021-4104
  • 让这成为我们的一个教训——不要升级到最新版本!
  • 也许我可以自己回答... JMSAppender 必须作为新的附加程序添加到 log4j 配置文件中(或通过代码),对吧?如果不是这种情况,则此漏洞没有问题。 -- 现在有一个 CVE:nvd.nist.gov/vuln/detail/CVE-2021-4104
  • 值得指出的是,虽然 Log4j 1.x 并非以同样的方式易受攻击,但它此时已打开多个 CVE(nvd.nist.gov/vuln/detail/CVE-2021-4104nvd.nist.gov/vuln/detail/CVE-2019-17571)并且已经结束- 自 2015 年 8 月以来的生活 (blogs.apache.org/foundation/entry/…)。可能值得考虑的是,“如果已经有多个漏洞利用,还能发现什么?”对于不再接收更新的库。
【解决方案2】:

虽然不受完全相同的 Log4Shell 问题的影响,Apache Log4j team 建议从您的 JAR 文件中删除 JMSAppenderSocketServer,它们在 CVE-2019-17571 中存在漏洞。

您可以使用zip 命令删除受影响的类。将文件名/版本替换为您的:

zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class
zip -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class

您可以使用 lessgrep 浏览 zip 中的文件,例如less log4j-1.2.16.jar | grep JMSAppender

话虽如此,Apache 建议您尽可能升级到 2.x 版本。根据their security page

请注意,Log4j 1.x 已结束生命周期,不再受支持。 2015 年 8 月之后报告的针对 Log4j 1.x 的漏洞没有经过检查,也不会修复。用户应升级到 Log4j 2 以获得安全修复。

【讨论】:

  • 只是提醒一下 - log4j jar 文件仍将驻留在已部署的 war 文件和开发人员 maven 存储库中。因此,应用程序的任何重建和使用这些重新部署都将重新引入这些类。
【解决方案3】:

除了giraffesyo's answer,如果它可以帮助任何人——我写了这个 Bash 脚本——它删除了被识别为漏洞的类(链接here to Log4j dev thread)并将属性文件设置为只读——正如建议的here on a Red Hat Bugzilla thread

注意 1 - 它不检查这些类在属性中的任何使用,它纯粹是一种查找和删除的方法 - 使用风险自负!

注意 2 - 这取决于正在安装的 zipunzip

#!/bin/bash

DIR=$1
APPLY=$2

# Classes to be searched for/removed
CLASSES="org/apache/log4j/net/SimpleSocketServer.class
org/apache/log4j/net/SocketServer.class
org/apache/log4j/net/JMSAppender.class"


PROGNAME=`basename $0`
PROGPATH=`echo $0 | sed -e 's,[\\/][^\\/][^\\/]*$,,'`

usage () {
    echo >&2 Usage: ${PROGNAME} DIR [APPLY]
    echo >&2        Where DIR is the starting directory for find
    echo >&2        and   APPLY = "Y" - to perform purification
    exit 1
}

# Force upper case on Apply
APPLY=$(echo "${APPLY}" | tr '[:lower:]' '[:upper:]')

# Default Apply to N
if [ "$APPLY" == "" ] ; then
   APPLY="N"
fi

# Check parameters
if [ "$DIR" == "" ] ; then
   usage
fi
echo $APPLY | grep -q -i -e '^Y$' -e '^N$' || usage

# Search for log4j jar files - for class file removal
FILES=$(find $DIR -name *log4j*jar)
for f in $FILES
do
   echo "Checking Jar [$f]"

   for jf in $CLASSES
   do
      unzip -v $f | grep -e "$jf"
      if [ "$APPLY" = "Y" ]
      then
         echo "Deleting $jf from $f"
         zip -d $f $jf
      fi
   done
done

# Search for Log4j properties files - for read-only setting
PFILES=$(find $DIR -name *log4j*properties)
for f in $PFILES
do
   echo "Checking permissions [$f]"

   if [ "$APPLY" = "Y" ]
   then
      echo "Changing permissons on $f"
      chmod 444 $f
   fi

   ls -l $f
done

【讨论】:

    猜你喜欢
    • 2022-01-17
    • 2022-01-22
    • 2022-01-17
    • 2022-01-16
    • 2022-01-16
    • 2022-01-18
    • 2022-01-20
    • 2010-11-05
    • 2011-02-02
    相关资源
    最近更新 更多