Apache Log4j  2安全漏洞

最近，Apache Log4j 2 漏洞闹的甚嚣尘上。Apache Log4j 2 是一个基于 java 的日志组件，被广泛应用于与 java 语言相关的软件或组件中。由于 java 在编程语言中的市场份额非常高，所以此次漏洞带来的影响非常大。各企业或组织都采取了积极的措施来应对此次漏洞事件。

此次漏洞的 ID 为 CVE-2021-44228，关于此次漏洞的详细内容及修复手段，我们建议查看 CVE 官网或者 NVD 官网。一切以官网解释为准。

首先，需要说明的一点是极狐GitLab 以 Ruby，Go 为主要语言，所以此次漏洞并未对极狐GitLab 产品产生影响。具体的讨论大家可以在这儿查看阅读。但是众所周知，极狐GitLab 是一个一体化的 DevOps 平台，同时具备很强的安全功能，其 DevSecOps 有七大功能：容器镜像扫描、静态应用安全测试 (SAST)、动态应用安全扫描（DAST）、密钥检测、License合规、依赖项扫描以及模糊测试。极狐GitLab DevSecOps 功能能够精准的扫描此次漏洞。

极狐GitLab Dependecny scanning 扫描 Apache log4j  2 漏洞

01 极狐GitLab Dependency scanning

Dependency scanning 是极狐GitLab DevSecOps 的重要功能之一。可以对多种语言（Ruby、PHP、Java、Python、C# 等）进行依赖扫描。核心原理是以 Gemnasium为扫描器（analyzer），对特定语言的特定文件（如 java maven 项目的 pom.xml）进行扫描，通过和漏洞数据库的对比，进而发现存在漏洞的依赖项，最后出具详细的漏洞报告。当然，最重要的是这种安全扫描可以和 MR、CI/CD 进行无缝集成，打造端到端的 DevSecOps 交付。

02 扫描示例

下面以 java maven 项目为例演示极狐GitLab DevSecOps 的 Dependency scanning 功能。

java maven 项目的目录结构如下：

$ tree
.
├── pom.xml
├── README.md
└── src
    └── main
        └── java
            └── com
                └── example
                    └── hello
                        └── Hello.java

pom.xml 文件中，关于 log4j 的依赖描述如下：

    
        org.apache.logging.log4j
        log4j-api
        2.11.0
        
    
        org.apache.logging.log4j
        log4j-core
        2.11.0
    

Hello.java 的内容如下：

package com.example.hello;

import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;

public class Hello {

  privatestatic Logger log = LogManager.getLogger(Hello.class.getClass());

  public static void main(String [] args) {
    log.error("this is ERROR message!!");
    log.info("this is INFO message!!");
    log.debug("this is DEBUG message!!");
  }

}

接着将上述代码放到一个目录下，用如下命令来启动一个 analyzer 环境：

$ docker run --rm -it -v $PWD:/code/ \
  registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven:2 sh

可以看到，容器里面安装了 analyzer，用 --help 来查看用法：

$ ./analyzer --help
Using java version 'adoptopenjdk-11.0.7+10.1'
[INFO] [gemnasium-maven] [2021-12-15T02:47:19Z] ▶ GitLab gemnasium-maven analyzer v2.24.2
NAME:
   analyzer - GitLab gemnasium-maven analyzer v2.24.2

USAGE:
   analyzer-binary [global options] command [command options] [arguments...]

VERSION:
   2.24.2

AUTHOR:
   GitLab

COMMANDS:
   find, f  Find compatible files in a directory
   run, r   Run the analyzer on detected project and generate a compatible artifact
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --help, -h     show help (default: false)
   --version, -v  print the version (default: false)

用 ./analyzer run --target-dir $CODE_PATH 即可完成依赖扫描，如所示：

./analyzer run --target-dir /code/
Using java version 'adoptopenjdk-11.0.7+10.1'
[INFO] [gemnasium-maven] [2021-12-15T04:34:40Z] ▶ GitLab gemnasium-maven analyzer v2.24.2
[INFO] [gemnasium-maven] [2021-12-15T04:34:40Z] ▶ Detected supported dependency files in '.'. Dependency files detected in this directory will be processed. Dependency files in other directories will be skipped.
[INFO] [gemnasium-maven] [2021-12-15T04:34:46Z] ▶ Using commit edc7d7c91a65271359d784d984dac2a83213576d
 of vulnerability database

在扫描路径下有一个名为 gl-dependency-scanning-report.json 的扫描报告文件:

$ ls -ltr gl-dependency-scanning-report.json
-rw-r--r-- 1 root root 6271 Dec 1502:48 gl-dependency-scanning-report.json

在报告里面可以看到，已经扫描出此次 log4j 2 的漏洞，ID 为 CVE-2021-44228，并且给出了 CVE 和 NVE 的链接、修复措施等其他详细内容，如下图所示：

当根据扫描报告给的修复策略，将 log4j 相关组件升级到 2.16.0 即可修复此次漏洞，接着可以再次扫描，发现报告中没有与 log4j 相关的漏洞数据了，如下图所示：

为了进一步验证极狐GitLab Dependency Scanning 的准确性，以此次受影响的 flink(1.14.0)为例进行了一次扫描，在 flink/flink-connectors/flink-connector-elasticsearch-base 目录下进行扫描，其 pom.xml 文件对 log4j 的描述如下：

        org.apache.logging.log4j
        log4j-api
        provided



        org.apache.logging.log4j
        log4j-core
        test

扫描结果如下：

可以看出，扫描出了 CVE-2021-44228 这个漏洞。当然，flink 最新版本已经没有这个漏洞了。上述流程可以无缝和极狐GitLab CI/CD 进行集成，从而真正做到 DevSecOps 提倡的“安全左移”以及“安全持续自动化”。我们会在后续的文章详细解析。

在此，我们也呼吁使用 log4j 2 组件的用户及时更新相关组件、软件来保证自己软件的安全。

Apache Log4j 2 安全漏洞启示录

此次 Apache log4j 2 漏洞是一个比较典型的软件供应链安全漏洞案例。log4j 是一款开源软件（从漏洞爆发之后的相关新闻可以看到，此项目的维护者是利用自己的的业余时间在维护这个至关重要的组件），是软件供应链的 upstream，而众多用户（企业、组织、个人）是 downstream，这种 upstream 组件受影响，进而导致大面积 downstream 受影响，就是典型的软件供应链安全特征：upstream 的一点可以影响 downstream 整个面，范围广，影响大。

此次漏洞也带来一些思考：

安全漏洞无法避免

安全漏洞伴随着软件的诞生而产生，是无法避免的。只要用合适的手段去尽早发现安全漏洞，及时制定修复策略，就可以避免自己所在的企业或组织遭受因安全漏洞带来的重大安全风险甚至经济损失。比如近些年常见的 DevSecOps 就是一种非常好的保障软件安全交付的理念。将安全贯穿在软件研发的整个生命周期中，人人为安全负责，进而保障软件的安全交付。

开源软件供应链安全

开源改变了软件的交付模式，开源的采用率也在大大提高。但是开源带来的风险也在增加。像 log4j 这样现代软件基石的开源软件还有很多，比如 openssl。一旦这些基石发生安全漏洞，就会造成很大的影响。因此，软件安全应该上升到软件供应链安全这个层次，也就意味着需要软件研发、分发、流通的各个环节都能够保持足够的透明，加上多方的通力协作与沟通，进而保证软件的安全。关于开源软件供应链安全的详细内容可以查看文章开源时代：。

Upstream First

Upstream first 理念是参与开源贡献的正确方式：所有的贡献（功能开发、软件分发、漏洞修复、决策制定）都发生在 upstream。一旦有发现安全漏洞，就在 upstream 直接进行修复，这样所有下游只需要更新相关软件版本即可。关于 Upstream first 理念，可以查看文章 。

引用链接