openLooKeng 开源社区 Apache Log4j2 高危安全漏洞修复完成,建议用户升级
近日,openLooKeng注意到Apache Log4j2反序列化远程代码执行漏洞(CVE ID为CVE-2021-44228),并成功进行修复。详细方案如下,建议所有用户升级。
Apache Log4j2远程代码执行漏洞修复解决方案
【漏洞描述】
Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架,并引入了大量丰富的特性。该日志框架被广泛地用于中间件、开发框架与Web应用中,用来记录日志信息。
由于组件存在 Java JNDI 注入漏洞,当程序将用户输入的数据记入日志时,攻击者通过构造特殊请求,来触发 Apache Log4j2 中的远程代码执行漏洞,从而利用此漏洞在目标服务器上执行任意代码。目前POC已公开,风险较高。
【漏洞等级】
高危,该漏洞影响范围极广,危害极大。 CVSS评分:9.8
【受影响版本】
Apache log4j 2 在 2.0 至 2.14.1 (均含)版本均受影响。
【openLooKeng漏洞排查】
问题排查一: ESconnector在运行时依赖log4j
继续排查openLooKeng最终打包server时的jar包,当前使用的是JDK自己的logging框架,没有使用log4j。
在对应的ES connector模块下,对lib库的分析,发现的确使用了log4j相关的库。
问题排查二:openLooKeng使用的是airlift,封装的JDK本身的log框架
同样对打包后的openLooKeng server lib库下所有的jar包进行梳理,可以看到没有log4j-api以及log4j-core。
问题排查三 :openLooKeng仓库ranger plugin代码
通过排查仓库的内容,并未发现相关log4j相关代码的依赖。 在ranger中的POM文件中,发现了部分关于log4j的版本声明,但是并未在后续的构建中使用。
当前openLooKeng ranger plugin依赖于apache ranger 2.1.0组件,而ranger 2.1.0组件依赖log4j2 2.13X版本,为间接依赖关系。
并且,当前ranger中,对于log4j有依赖的模块是agents-audit
openLooKeng的ranger plugin并不依赖log4j
【openLooKeng社区修复方案】
升级至最新组件:log4j-2.15.0,其中2.15.0的发布时间应该为2021-12-09 23:46的版本!
◎ 方案1 - 修改代码
针对ES connector 和Ranger plugin,更新代码,移除log4j的依赖。关联PR如下 :
https://gitee.com/openlookeng/hetu-core/pulls/1312
https://gitee.com/openlookeng/openlookeng-ranger-plugin/pulls/10
备注:由于Ranger社区尚未修复log4j问题,因此建议用户在使用ranger plugin时,按照方案2的建议配置openLooKeng参数。openLooKeng社区会在ranger社区修复log4j2问题之后更新ranger到最新版本。
◎ 方案2 - 修改配置规避问题
针对无法做代码改动的环境,如已在生产环境部署openLooKeng 1.4.0之前的版本。建议在JVM.config文件中,添加如下配置:
-Dlog4j2.formatMsgNoLookups=true
上述便是openLooKeng针对Apache Log4j2反序列化远程代码执行漏洞(CVE ID为CVE-2021-44228)所提供的修复方案,当前漏洞状态已修复。详细文档可参考: https://openlookeng.io/zh-cn/security/2021-1213/sa-v2.html
欢迎使用openLooKeng,如果您有任何疑问与建议,请在社区代码仓中提Issue,或加小助手进入专属交流群。
openLooKeng, Make Big Data Simplified
社区官网
代码仓地址
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Deepin、Kratos、Vue.js…欢迎投票「最受欢迎项目」
评选活动设置「最受欢迎项目」,以及特别策划的「优秀中国开源原生创企」和「最具情怀奖」,本页面用于投票选出「最受欢迎项目」; 参与投票的候选项目被划分到「组织」或「个人」通道,最终选出 TOP 30 项目(组织:21 个,个人:9 个) 详细规则点此查看; 候选开源项目均由国人发起,评审委员会筛选出本页面的候选项目; 提名、修改项目信息等相关问题请私信 @OSCHINA编辑部。
- 下一篇
让容器跑得更快:CPU Burst 技术实践
作者:常怀鑫、丁天琛 让人讨厌的 CPU 限流影响容器运行,有时人们不得不牺牲容器部署密度来避免 CPU 限流出现。我们设计的 CPU Burst 技术既能保证容器运行服务质量,又不降低容器部署密度。CPU Burst 特性已合入 Linux 5.14,Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3 也都支持 CPU Burst 特性。 在 K8s 容器调度中,容器的 CPU 资源上限是由 CPU limits 参数指定。设置 CPU 资源上限可以限制个别容器消耗过多的 CPU 运行时间,并确保其他容器拿到足够的 CPU 资源。CPU limits 限制在 Linux 内核中是用 CPU Bandwidth Controller 实现的,它通过 CPU 限流限制 cgroup 的资源消耗。所以当一个容器中的进程使用了超过 CPU limits 的资源的时候,这些进程就会被 CPU 限流,他们使用的 CPU 时间就会受到限制,进程中一些关键的延迟指标就会变差。 面对这种情况,我们应该怎么办呢?一般情况下,我们会结合这个容器日...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8编译安装MySQL8.0.19
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS关闭SELinux安全模块
- MySQL8.0.19开启GTID主从同步CentOS8
- 设置Eclipse缩进为4个空格,增强代码规范
- SpringBoot2整合Redis,开启缓存,提高访问速度