开源组件风险修复，升级版本就够了吗？

通常情况下开源组件风险的修复建议是升级版本。但是这样就够了么？近日，开源安全研究院研究员发现了风险修复里一些很有意思的点。

 

1.开源安全研究院先是对MeterSphere的1.18.0版本进行了开源组件的安全检测发现了存在风险并向MeterSphere提出了修复的建议，MeterSphere也对此表示了感谢。

 

2.随后绿盟发现MeterSphere开源持续测试平台的三处漏洞并上报，MeterSphere对此表示了感谢并且升级版本为1.18.1。

 

3.这时开源安全研究院开始思考为何最初并未发现这几处漏洞呢？随即对绿盟发现的XXE漏洞进行了复现，最终发现了问题Dom4j 2.1.3上。

 

4.在经过问题的验证后，开源安全研究院向Dom4j的作者提出了修复建议。随后得到作者的回复则是：出于对现有办法具备向后兼容性的特性的考虑，他认为目前没有更优的新办法来解决该项的修复问题。

 

5.组件的版本已经声称修复了，然而漏洞代码依旧存在且还能被使用，也就是说还存在风险。倘若不做代码的分析，还无法知道存在问题。其次向开源作者提出修复建议，但对方考虑向后兼容问题，暂时也不会对此进行修复。

 

所以开源组件风险修复，真的是升级版本就够了吗？

MeterSphere的扫描检测及建议

开源网安研究院通过对MeterSphere的最新版本1.18.0进行开源组件安全检测。发现引用了存在‘超危’、‘高危’安全风险漏洞的开源组件15个

 

对metersphere1.18.0提出了对以上开源组件更新，防止存在被利用风险的修改意见。

 

MeterSphere一站式开源持续测试平台1.18.0于2022年2月28日正式发布并对深圳开源互联网安全技术有限公司反馈的若干安全漏洞表示了特别鸣谢。

（原文链接：

https://mp.weixin.qq.com/s/JNTksqArR1d0kbOdbYIzjQ）

 

MeterSphere漏洞通知及修复方案

2022年3月3日，LaiHan of NSFOCUS Security Team 发现了MeterSphere开源持续测试平台的三处漏洞，并向MeterSphere开源项目进行上报。漏洞包括:

1.   未授权XXE漏洞（使用SAXReader导致的未授权XXE攻击漏洞）

2.   Prometheus未授权访问漏洞（Prometheus组件未授权访问导致的敏感信息泄露）

3.   getMdlmage函数未授权调用漏洞

 

现MeterSphere版本升级为1.18.1。并且MeterSphere开源社区对LaiHan of NSFOCUS Security Team的及时反馈漏洞表示感谢。

 

（原文链接：

https://mp.weixin.qq.com/s/A4GpuBIIZZ7PptROIJJAaA）

为什么先前扫描未发现该漏洞？

开源安全研究院觉得很奇怪，为什么我们之前进行扫描检测时没有发现这个漏洞呢？

然后对绿盟发现的XXE漏洞进行了复现。最终发现问题出在Dom4j 2.1.3

但是Dom4j 2.1.3被认为是安全的，因为CVE-2020-10683漏洞已经被官方宣传修复。

Dom4j2.1.3 XXE XML外部实体注入漏洞思考

Dom4j 是一款开源的java 解析XML文件与数据的库(https://github.com/dom4j/dom4j)

在2020.6.6公开披露了一个CVE-2020-10683 默认配置XXE漏洞，随后官方在最新版2.1.3进行了修复，但是官方修复方案存在一些问题：
1、必须要求用户重写调用SAXReader 代码，才能避免XXE漏洞。

2、但是原有的用户调用SAXReader 的代码（通过构造函数创建对象）依然可以正常使用，且依然存在XXE漏洞。（Dom4j 官方并没有修复SAXReader 构造函数中禁用解析外部实体DTD）。

所以容易造成：用户得知需要升级有漏洞的Dom4j库，以为升级到了最新的2.1.3版本，就安全了，而没有修改自有代码中调用SAXReader 代码，最后的结果就是：即使升级了Dom4j,但是漏洞依然存在。

官方修复方案

1、Dom4j 2.1.3提供一个静态 createDefault关闭解析外部实体DTD。从而修复了该漏洞。（src/main/java/org/dom4j/io/SAXReader.java）

 2、Dom4j 2.1.3 DocumentHelper.parseText(String text) 中调用 createDefault关闭解析外部实体DTD，表明也修复了该漏洞。
（src/main/java/org/dom4j/DocumentHelper.java）

 3、官方修复后的建议：

 

a)   使用安全的SAXReader.createDefault() 创建 SAXReader对象。

b)   使用安全的DocumentHelper.parseText(String text)解析XML数据。

官方修复补丁：

https://github.com/dom4j/dom4j/commit/a822852

修复后存在的问题

现开源安全研究院发现官方修复方案存在的问题：

 

1、升级到了最新的2.1.3版本，用户必须修改使用代码，不然漏洞依然存在，原因在于Dom4j 官方并没有修复SAXReader 构造函数中禁用解析外部实体DTD。

 

SAXReader .read 方法中也没有禁用解析外部实体DTD。

 

问题验证：

1、继续使用SAXReader构造函数创建对象，使用Read方法，XXE依然存在：

 

 

 2、使用官方建议 SAXReader.createDefault() 创建 SAXReader对象，规避了XXE

 

 

 3、使用官方建议DocumentHelper.parseText(String text)解析XML数据，规避了XXE。

 

 

 对于该组件的问题开源安全研究院向Dom4j提交了该漏洞，但是该组件作者出于对现有办法具备向后兼容性的特性的考虑，他认为目前没有更优的新办法来解决该项的修复问题。

 （组件作者回复如下图）

 

现开源安全研究院总结并建议：

Dom4j 官方的修复方案，不完整，建议用户使用最新的修复后的
DocumentHelper.parseText与static createDefault。
而原有的用户调用代码，通过SAXReader()默认构造函数后，调用Reader却没有修复，或者没禁止用户使用构造函数调用，造成用户只升级Dom4j 而不修复自有调用代码，XXE漏洞依然存在。

建议：

1、 Dom4j 库官方继续修复，要么禁用旧的调用方式，要么在SAXReader()构造函数中禁用解析外部实体DTD。

2、 对于开源库使用者：在得知某个开源库有漏洞需要修复，不要简单的升级补丁后的开源库，而是需要进一步验证，自有代码调用最新的库时候，漏洞是否真正得到了修复。

开源安全

Gartner报告曾指出，在当前DevOps的模式下，应用程序中大部分的代码都是被组装出来的而不是开发出来的。有数据表明超过95%的组织在业务中有直接或者间接地使用了重要的开源软件。而Forrester Research的研究也表明，应用软件的百分之八十到百分之九十的代码来源于开源组件。因此开源组件的安全性也直接关系到信息系统基础设施的安全。

根据开源安全院的研究调查发现开源安全软件的安全性不容乐观。这也成为了近日软件供应链安全问题增长的重要因素。

 

开源安全研究院现展开对开源项目的安全分析研究，将从三个方向上对开源安全做出贡献。

 

（一）软件安全爱好者

可为软件安全爱好者提供更多开源项目的安全分析报告。与此同时开源安全研究院现搭建了一个免费的DevSecOps平台git.gitsec.cn，可为软件安全爱好者提供一个完整的DevSecOps实验环境。

 

（二）开源项目厂商

可以与开源项目厂商进行战略合作对开源项目存在的安全问题进行深入的交流合作，共同进步。

 

（三）创建开源项目安全交流社群

对开源项目及其安全感兴趣的开发者、厂商及专家提供交流平台，希望能共同维护开源生态平衡并共同进步。

（感兴趣的可以扫码进群）