如何在Linux中查看log4j的版本号？

Question

如何在Linux系统中快速确定Java应用所使用的log4j版本号？由于log4j2存在严重安全漏洞（如CVE-2021-44228），准确定位其版本至关重要。常见问题包括：jar包未明确命名版本、多个log4j依赖共存、或仅部署了class文件而无pom.xml。直接通过java -jar无法查看，需借助命令行工具从JAR文件的MANIFEST.MF或类路径中提取版本信息。如何在无Maven/Gradle环境的生产服务器上，使用find、grep、unzip等常用Linux命令精准识别当前加载的log4j-core或log4j-api版本？这是运维和安全排查中的典型难题。

Answer 1

一、问题背景与挑战分析

在当前Java应用广泛部署的生产环境中，Log4j2因其高性能日志处理能力被大量使用。然而，自2021年爆出CVE-2021-44228（即“Log4Shell”）以来，准确识别系统中实际加载的Log4j版本成为安全运维的关键任务。

常见的现实困境包括：

• JAR包命名不规范（如 log4j-core.jar 而非 log4j-core-2.14.1.jar）
• 多个版本共存导致类路径冲突
• 仅部署编译后的class文件，缺失pom.xml或build.gradle
• 无法重启服务以启用调试参数
• 生产环境无Maven/Gradle等构建工具支持

因此，必须依赖Linux原生命令行工具进行快速、精准的版本探测。

二、基础排查方法：定位相关JAR文件

首先需通过文件系统搜索，找出所有可能包含Log4j组件的JAR包。

# 查找所有包含log4j关键字的jar文件
find /opt/app -name "*.jar" | grep -i log4j

# 或者更通用的方式，基于内容匹配
find /opt/app -name "*.jar" -exec jar -tf {} \; | grep -i "log4j" | sort | uniq

上述命令可列出所有包含Log4j类的JAR包路径，为进一步提取版本信息做准备。

三、中级方案：解析MANIFEST.MF获取元数据

Java JAR包中的META-INF/MANIFEST.MF通常包含版本信息。可通过以下方式提取：

# 针对单个JAR提取版本
unzip -p log4j-core.jar META-INF/MANIFEST.MF | grep "Implementation-Version"

# 批量处理多个JAR并输出结果
for jar in $(find . -name "log4j-core*.jar"); do
    echo "=== $jar ==="
    unzip -p "$jar" META-INF/MANIFEST.MF | grep -E "(Implementation-Version|Bundle-Version)"
done

四、高级技巧：从Class字节码中提取版本常量

当MANIFEST.MF缺失时，可直接读取org.apache.logging.log4j.core.impl.Log4jContextFactory类中的版本字段。

# 提取Log4j核心类中的版本字符串
unzip -p log4j-core.jar org/apache/logging/log4j/core/impl/Log4jContextFactory.class | strings | grep "^[0-9]\+\.[0-9]\+\(\.[0-9]\+\)\?"

该方法利用strings命令提取可打印字符串，过滤出符合版本格式的内容，适用于大多数Log4j 2.x版本。

五、综合判断流程图

graph TD A[开始] --> B{是否存在pom.xml?} B -- 是 --> C[使用mvn dependency:tree] B -- 否 --> D[使用find查找*.jar] D --> E[筛选含log4j的JAR] E --> F[检查MANIFEST.MF版本] F --> G{是否成功?} G -- 否 --> H[解压class并strings分析] G -- 是 --> I[记录版本号] H --> I I --> J{是否多版本共存?} J -- 是 --> K[结合jcmd确定运行时加载路径] J -- 否 --> L[输出最终确认版本]

六、运行时验证：结合JVM进程动态确认

即使找到磁盘上的JAR，也不能保证其被实际加载。应结合JVM运行时信息确认：

# 获取Java进程PID
jps -l | grep YourApp

# 输出类加载路径
jcmd <pid> VM.system_properties | grep "java.class.path"

# 使用jinfo查看启动参数中的classpath
jinfo <pid> | grep classpath

随后可在classpath路径中重点检查被引用的log4j-core.jar。

七、自动化脚本示例

以下是一个集成化检测脚本，可用于批量服务器扫描：

步骤	命令	说明
1	find_app_jars()	定位应用目录下的所有JAR
2	filter_log4j_jars()	筛选含log4j类的JAR
3	extract_from_manifest()	尝试从MANIFEST读取版本
4	fallback_strings_analysis()	失败则用strings分析class
5	check_runtime_classpath()	比对运行时加载路径
6	output_report()	生成JSON格式报告

#!/bin/bash
detect_log4j_version() {
    local jar="$1"
    local version=$(unzip -p "$jar" META-INF/MANIFEST.MF 2>/dev/null | \
                   grep -E "(Implementation-Version|Bundle-Version)" | \
                   head -1 | cut -d: -f2 | xargs)
    if [ -z "$version" ]; then
        version=$(unzip -p "$jar" $(unzip -Z1 "$jar" | grep -E "Log4jContextFactory\.class") 2>/dev/null | \
                  strings | grep -oE "2\.[0-9]+(\.[0-9]+)?" | head -1)
    fi
    echo "$version"
}

八、注意事项与最佳实践

在执行过程中应注意以下几点：

1. 避免在高负载时段频繁调用unzip -p，防止I/O压力过大
2. 注意符号链接可能导致重复扫描同一文件
3. 某些混淆或裁剪版JAR可能移除了MANIFEST信息
4. 使用file命令验证是否为真实JAR而非ZIP伪装
5. 跨平台兼容性：确保目标系统有unzip/jar/strings等工具
6. 权限问题：部分JAR位于受保护目录，需sudo访问
7. 日志归档包（tar.gz）也应纳入扫描范围
8. 考虑Docker容器内部文件系统的隔离性
9. 定期更新漏洞指纹库用于自动化比对
10. 建立资产清单，持续监控第三方库变更