华为PSIRT：《Finite State供应链评估》的技术分析报告

• 更新发布时间： 2019年07月03日

华为愿意与网络安全研究人员合作，也欢迎对我们的产品和解决方案进行独立测试。我们早已建立了华为公司产品安全应急响应团队（PSIRT），负责收集、调查、内部协调及负责任地披露华为产品相关的安全漏洞信息。一旦确认漏洞，PSIRT会及时将信息传递给受影响产品的团队，并积极跟踪直至问题解决。

华为建立并实施了一套分层的端到端网络安全评估流程，确保在各阶段（概念、设计、开发、直到在全球客户网络中部署和维护）都对产品进行审视，以发现潜在的安全问题。

2019年6月26美国公司 Finite State（如下简称“F公司”）在其官方网站公布华为技术有限公司的《供应链评估》报告，该报告重点描述了其使用固件（二进制软件包）静态分析工具，分析了华为企业网络500多个产品，并对华为的CE12800和Juniper的EX4650、Arista的7280R产品做了对比分析，结果认为华为产品安全性差、有疑似后门，安全性低于友商。

我们对F公司有违常规的做法感到惊讶和失望。我们无法确认F公司软件获取的渠道是否合法，也不能保证其获取软件的完整性，同时华为也未曾收到F公司的任何沟通请求。他们也没有通过华为了解这些产品，并拒绝在公布前将报告提供给华为。遗憾的是，这意味着这份报告缺乏洞察力、完整性和准确性，F公司的这种做法也不是一个专业、认真、有能力的安全公司通常的做法。

鉴于F公司的做法及其工具和方法的不足，其分析结果，最好的情况下是种质疑，最差的情况下就是不准确的。若是通过合作而不是在安全方面选择政治立场的话，这本应是可以避免的。

我们不清楚F公司CEO Matt Wyckhouse及F公司目的何在，为何他们没有选择市场领导者Cisco公司的产品来做比较，为何评估的是华为产品的老版本，发现的是已经在新版本中修复的问题。

F公司花费几个月时间进行了一项有问题的分析，而华为PSIRT在公布报告后第一时间对报告中提到的所有问题进行了调查，我们认为F公司的方法存在严重的操作和技术缺陷，测试缺乏中立性，报告严重失实。

1   F公司的测试过程和输出测试报告的方法与业界负责任的安全测试公司的做法相悖

     负责任的安全问题或漏洞的披露在业界广泛认可和实践的，安全研究组织或研究员通常是把发现的问题、疑似漏洞提交给厂商，由厂商确认是不是缺陷和漏洞，协调处置。F公司使用工具对原始二进制文件进行扫描，对部分疑似问题通过简单的局部逆向分析得出结论，未在实际产品中做漏洞利用来验证并经过华为公司产品研发人员实际确认，由于二进制漏洞扫描工具常常错误率误差达到90%以上，一般作为辅助分析工具，匆忙得出结论是非常不准确的。尽管F公司在报告里面也写了自己开发的这款工具的局限性，例如不能支持上下文分析，漏洞是基于文件名和版本信息等，F公司显而易见的高估了自己工具的先进性和准确性。正如附录中所述，独立分析师认为F公司的工具在所有维度都未位居前列。

     F公司评估报告公开前未提供给华为公司，问题也未经华为公司确认，就非常不专业地把报告快速提交给媒体和政府机构，这种做法与业界负责任的安全组织的最佳实践甚至基本做法完全相悖。公正的安全技术组织本应该持中立的立场，从技术安全角度陈述其观点。

     F公司评估报告中大量使用潜在后门这种情绪化、夸大性语言。任何一家安全公司，如果在仅经过工具的扫描，未在产品上进行实际验证，甚至对产品、产品架构及环境根本不了解的情况下，就声称发现大量后门和未修补的严重漏洞，是无法让人信赖的。

2   评估报告未就对比厂商选择、产品范围和版本选择给出任何说明，存在选择性测试

评估报告未就为什么选择华为、J和A公司作为测试样本，反而没有选择占全球市场企业网份额最大的思科公司产品作为测试对象。对华为公司选择了几乎所有企业网络的数百种产品，而只选择了J公司和A公司的各一款产品，且没有公布J公司、A公司产品的版本号。报告上声称选择的是华为最新版本，报告中实际引用的版本均为旧版本。例如选择AR1200 2017的版本V200R007C00SPCc00，华为技术支持网站上提供了2018年和2019年的更新的版本可供下载，如V200R010、V200R009。再例如选择的AR3600 2016年发布的版本V200R007C00SPCb00，但是2018和2019年有V200R008、V200R009等新版本可供下载。

我们不得不怀疑这是否在做选择性测试，从众多版本中选择版本和精心选择的对比测试对象，以得到F公司及资助此“研究”的相关方“期望”的结果。

3   经过调查分析，F公司得出的结论与事实不符

F公司报告上提到的后门问题和众多漏洞甚至严重漏洞未修补的问题，华为PSIRT与产品研发共同进行了详细分析，经验证后得出如下结论。

3.1  存在疑似后门的分析

F公司分析得出很多关于疑似后门结论都是基于“Huawei is using standard Linux-based authentication”的前提，我们发现该前提是错误的，进而导致了后面一系列分析结论的错误。

3.1.1  未公开及硬编码凭据的分析

报告中提到的存在huawei/python/root账号作为疑似提权后门，这三个账号实际上并不能用于非法提权，分析如下：

华为AR产品仅使用Linux系统的最基础功能，如任务调度，而用户管理、远程接入控制和TCP/IP协议栈由华为开发的VRP（Versatile Routing Platform）接管。这种设计能更好的满足产品的应用需要，业界众多通信公司产品也采用类似的设计，如下图所示。

图：VRP接管远程用户接入

其中root用于拉起VRP进程，属于程序内部使用，外部不可见；python/huawei两个账户，是VRP最高权限用户用来创建虚机和安装第三方应用时使用的，外部不可见。这三个账号无法被用来远程接入设备，不影响系统的安全性。

当然，报告所提到的sudo /sbin/insmod可能被利用越权等风险，华为PSIRT确认这是已知且已修复的漏洞，考虑到对设备管理员本身也应该尽可能的赋予最小权限，减少风险，华为已在V300R003C00SPC500版本（2018年8月发布）修改为用程序代码来实现相关的管理功能，消除了风险。

另外，在2018年版本用户手册中对huawei/python/root这三个账号有明确说明，具体可参考配套文档。

3.1.2  默认的硬编码加密密钥的分析

正如报告本身所述，通常类似于authorized_keys的文件是在开发过程中为了便利软件工程活动而引入。E9000和CE12800产品研发工程师为了方便调试，使用了Linux OS的SSH，在firmware中遗留了key文件。

      基于如上3.1.1中已经说明的华为数通产品使用Linux的方式，远程接入控制和TCP/IP协议栈由VRP（Versatile Routing Platform）接管，正式发布版本中，关闭了调试功能，外部无法访问Linux OS的SSH，因此可以确认这些key文件不会导致任何潜在的非法接入，2019年9月发布的版本中，将对这些遗留key文件进行清除。

      报告描述SmartAX MA5800固件中发现存在超级用户帐户的authorized_keys文件，在其发布版本中SSH功能代码都已被删除，无风险。

3.2  存在未修复已知漏洞的分析

      报告中关于过时组件使用的描述，我们认为有一定道理，并且已经宣布开展大量升级以提升产品能力。但使用过时组件并不代表一定存在安全问题。

报告中使用的组件已知漏洞分析方法(SCA)，是基于开源软件名称与版本号来评估已知漏洞，在嵌入式设备上存在缺陷，主要原因：

1、开源组件漏洞相关代码未编译到固件中。

2、有些开源软件在发现漏洞后，会优先发布修复漏洞的源代码补丁，然后规划正式的修复漏洞版本，但该周期可能很长，取决于开源社区采取的方法。电信设备厂商为了尽快修复漏洞，往往会合入该修补漏洞的源码解决问题，但产品固件中使用的开源软件版本号还是之前的旧版本号。

3、通过二进制方式修复漏洞的方式与2）类似，开源组件软件版本号也未修改。

4、开源组件中漏洞相关代码虽然包含在固件中，但对应功能模块没有被使用。

针对报告中提到的AR3600 V200R007C00SPCb00存在10个已知漏洞的情况，经过分析确认，其中 6个不受影响、2个已修复，2个风险低，细节如下：

3.3  关于华为公开CVE漏洞数量增加而状态变差的分析

在报告的23页中，F公司基于漏洞披露数量的增加得出趋势变坏的结论是不科学的。

在漏洞修复后对客户进行披露，进行风险和削减措施告知是ISO/IEC 29147:2018漏洞披露中的基本要求，华为PSIRT是一个专职的全球安全应急响应团队，遵循相关标准建立了华为漏洞响应流程，并于2012年建立安全漏洞披露的公开渠道。

从NVD公开收录的各厂商的漏洞数量可以看出排名TOP5的公司分别是微软、Oracle、apple、IBM和Google。

从微软漏洞历年变化看，漏洞数量保持在一定的水平，一方面表明了微软对安全的持续投入，另外一方面也体现了微软负责任的漏洞披露。且通过漏洞奖励计划鼓励大家发现漏洞。

链接：https://www.cvedetails.com/vendor/26/Microsoft.html

Cisco也有自己的漏洞披露渠道，从它披露的漏洞数量看，其漏洞数量也保持在一定的水平。

链接：https://www.cvedetails.com/vendor/16/Cisco.html

3.4  安全编码实践

3.4.1  安全函数分析

      报告中分析安全函数的方法，存在如下几个问题，导致结果不准确：

      1、评估中没有覆盖Huawei产品中大量的安全函数，如VOS_MemCpy_Safe、    VOS_nsprintf_Safe，使安全评估结果存在严重偏差。

      2、对不安全函数的理解不准确

         1）报告第33页中列出了一些不安全函数中，puts、memcmp、asprintf等不属于不安全函数。

         2）memset函数作为内存清0函数，在华为内部主要用于对新申请内存及固定长度数组清0，风险极低，连推出安全函数的微软公司都没有对应安全函数版本。

         3）fopen、access、system、remove、execl等函数是由于业务需要必须在代码中使用，使用与否与会不会造成漏洞没有直接关系。

      3、报告中将一些函数既作为安全函数又作为不安全函数，前后矛盾

         1）asprintf函数在报告第34页的"Top 20 Most Commonly Used Unsafe Functions"中列为不安全函数，但在报告第36页"Safe and Unsafe Function Collections"中又列为安全函数; drv_cvb_memcpy_s_impl在"Safe and Unsafe Function Collections"中既列为不安全函数，又列为安全函数(原报告第36页）。

         2）"Top 20 Most Commonly Used Unsafe Functions"，作者认为execl函数不安全，但是却认为execlp、execv、execve、execvp、execle、execvpe等函数安全，这是错误的。

3.4.2  安全编译选项分析

      安全编译选项除了报告中提到了RELRO、ASLR、DEP和StackGuard之外，至少还有另外三项是比较重要的；在嵌入式通信设备中，开启安全编译选项，通常会降低产品性能，甚至有些选项会导致产品功能无法正常运行；F公司仅仅用通用软件的视角来评价嵌入式通信软件的安全编译选项打开情况，表明F公司成熟度和能力不足。华为愿意帮助F公司了解嵌入式系统的基本知识及全球通信运营情况。

华为在安全编译领域有多年的深入研究，对安全非常重视，尽可能的会打开安全编译选项。据我们了解的情况，在通信行业内，华为在该技术的落地上是领先的；

附录：F公司软件成分分析方法原理介绍

      F公司测试报告中使用的分析方法SCA(Software Composition Analysis)技术与业界的分析方法一致，同时业界有很多公司都对外提供这种分析服务。研究机构Forrester关于SCA供应商的评估中并没有发现F公司。The Forrester Wave™: Software Composition Analysis, Q2 2019链接：https://reprints.forrester.com/#/assets/2/230/RES146435/reports。

       SCA分析原理

 当前业界通用的开源软件以及漏洞分析技术 SCA(Software Composition Analysis)主要目的有两个：

  1、识别软件中所使用开源软件版本、License 信息，确保开源软件使用合规性。

  2、根据开源软件版本到漏洞库中匹配，以得出开源软件的全部漏洞列表。

出处原文：来自于WhiteSource博客，WhiteSource是Forrester 评价的SCA方案提供商领导者

First and foremost, SCA tools generate an inventory report of all open source components in your products, including all direct and transitive dependencies. Taking inventory of open source usage is critical as it is the basis for properly managing your open source usage. After all, how can you secure or ensure compliance of something you do not know you’re using?

Once all open source components have been identified, SCA tools provide information on each component. Basic information includes the open source license and whether there’s a security vulnerability associated with that component.

该分析方法针对firmware的分析步骤大致如下：

  1、提取Firmware中每个二进制文件的完整哈希值、部分哈希值、函数符号名称、文件名称等作为特征。利用特征方式来识别Firmware中引用开源软件名称与版本。

  2、根据第1步中得到的开源软件名称、版本号信息，到漏洞库中检索并得该版本开源软件的全部漏洞信息。

 SCA分析结果只是一个中间结果，通常需要和firmware开发者做进一步确认。

修订记录：V1.1 UPDATED 增加Forrester Wave™: Software Composition Analysis, Q2 2019链接