logo标签列表

Log4j漏洞 - Log4j 1.2.17是否存在漏洞（源代码中未发现任何JNDI代码）？

javasecuritylog4jlog4j2exploit
61

关于已经被发现的CVE-2021-44228 Log4j JNDI 远程代码执行漏洞 - 也参考引用资料 - 我想知道Log4j-v1.2 是否也受到影响，但是通过源代码审查，我最接近的是JMS-Appender。

问题是，尽管互联网上的帖子表明Log4j 1.2也存在漏洞，但我找不到相关的源代码。

我是否错过了其他人已经确定的东西？

Log4j 1.2似乎在socket-server类中存在漏洞，但我的理解是，首先需要启用它才能适用，因此不像已经被识别的JNDI-lookup漏洞那样是一种被动威胁。

我的理解 - Log4j v1.2 - 不受jndi-remote-code执行漏洞的影响 - 正确吗？

参考资料

这篇来自Cloudflare的博客文章也指出了与AKX相同的观点……它是从Log4j 2引入的！

更新#1 - (现已停用的)apache-log4j-1.2.x的一个分支，其中包含旧库中识别出的少数漏洞的补丁修复，现在可用(由原始的log4j作者提供)。该站点为https://reload4j.qos.ch/。截至2022年1月21日，已发布版本1.2.18.2。迄今为止解决的漏洞包括涉及JMSAppender、SocketServer和Chainsaw漏洞。请注意我只是转达这些信息。我没有验证我的端的修复情况。请参考链接获取更多详细信息。

1
这个回答解决了你的问题吗？如何在log4j版本1.2中缓解log4shell漏洞？ - Piotr P. Karwasz
1
这很困难，因为指导仍在不断发展。我建议查看CISA专门为此设置的页面：https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance - Brent Writes Code
3个回答
40
13
原来log4j 1在某些配置下可能存在漏洞：https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 - AKX
正如我在评论中所提到的，是的，如果使用JMS Appender（显然很少使用），log4j 1.x可能会存在漏洞。 - AKX
1
让我们从中吸取教训 - 不要升级到最新版本！ - Sridhar Sarnobat
1
也许我可以自己回答这个问题... JMSAppender必须作为新appender添加到log4j配置文件中(或通过代码添加)，对吗？如果不是这样，那么关于此漏洞就没有问题了。-- 现在有一个CVE: https://nvd.nist.gov/vuln/detail/CVE-2021-4104 - Markus
6
值得指出的是，尽管Log4j 1.x并没有以同样的方式存在漏洞，但它在此时已经存在多个CVE（https://nvd.nist.gov/vuln/detail/CVE-2021-4104，https://nvd.nist.gov/vuln/detail/CVE-2019-17571），而且自2015年8月以来就已经停止更新（https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces）。考虑到一个不再接收更新的库已经存在多个漏洞，可能值得思考，“还会发现什么其他问题？” - Brent Writes Code
显示剩余6条评论
34
尽管没有受到完全相同的Log4Shell问题影响，Apache Log4j团队建议从您的JAR文件中删除具有CVE-2019-17571漏洞的JMSAppender和SocketServer。您可以使用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

使用 less 和 grep，您可以查看zip文件中的文件，例如：less log4j-1.2.16.jar | grep JMSAppender

话虽如此，Apache建议如果可能的话应升级到2.x版本。根据他们的安全页面：

请注意，Log4j 1.x已经停止维护，不再支持。2015年8月之后报告的针对Log4j 1.x的漏洞未经检查，也不会得到修复。用户应升级到Log4j 2以获取安全修复。

2
只是提醒一下 - log4j jar 文件仍将驻留在部署的 war 文件和开发者的 maven 存储库中。因此，任何应用程序的重建和重新部署都将重新引入这些类。 - Dazed
0

除了giraffesyo的回答之外，如果有帮助的话 - 我编写了这个Bash脚本 - 它会删除被识别为漏洞的类（链接在Log4j开发线程中），并将属性文件设置为只读 - 如建议在Red Hat Bugzilla线程中。

注意1 - 它不检查属性中对这些类的任何使用，它纯粹是一种查找和删除的方法 - 使用时自担风险！

注意2 - 它依赖于已安装zip和unzip

#!/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
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接