斯里兰卡信息技术研究所
作业 1
M. P. D. M. Dias
IT19165530
MLB_WD_Y2S1_13.1
点对点协议守护进程远程代码执行
漏洞 (CVE-2020-8597)
系统和网络编程– IE2012
内容
引言
点对点协议（PPP）是一种全双工协议，允许简单数据通过第2层或数据链路基础设施进行封装和分发，覆盖范围从拨号连接、DSL宽带到采用SSL加密的虚拟专用网（VPN）。由于这些协议不允许点对点通信，PPP也被用于在两个直连节点上强制实施IP和TCP。Pppd是一种用于类Unix操作系统上的守护进程，用于管理PPP会话的建立以及两个节点之间会话的终止。
PPP是用于通过拨号调制解调器、DSL连接以及多种其他点对点连接（如通过虚拟专用网，例如点对点隧道协议（PPTP））创建互联网连接的协议。pppd程序还可以对连接到网络的对端进行认证，和/或使用各种认证协议（如EAP）为对端提供认证详细信息。
由于点对点协议守护进程（pppd）在处理可扩展认证协议（EAP）数据包时存在缺陷，未经身份验证的远程攻击者可能导致栈缓冲区溢出，从而可能允许在目标系统上任意执行代码。此弱点的触发原因是：在将提供的数据复制到内存之前，对输入大小的验证存在错误。由于数据大小验证不正确，可能将随机数据复制到内存中，从而导致文件泄漏并引发意外代码执行。
该弱点存在于eap解析代码逻辑中，具体而言是eap_request()和eap_response()函数（位于eap.c中），这些函数由网络输入处理程序调用。这些函数将第一个字节作为类型，接受指针和长度作为输入。如果类型为EAPT_MD5CHAP(4)，则会查看一个嵌入式1字节长度区域。该代码的逻辑旨在确保嵌入的长度小于数据包的总长度。在此验证之后，它尝试将提供的数据（主机名）复制到嵌入式长度字段之后的本地栈缓冲区中。此边界检查不正确，允许以任意数据长度进行内存复制。
另一个逻辑错误导致eap_input()函数未测试在链路控制协议（LCP）过程中EAP是否已解析。这允许未经身份验证的攻击者发送EAP数据包，即使pppd由于不支持EAP或由于在LCP阶段未遵守预先商定的预共享密码而拒绝协商认证。在eap_input中，不安全的pppd代码仍然必须处理EAP数据包，从而导致栈缓冲区溢出。这些未经验证、大小未知的数据可用于破坏目标设备的内存。此外，pppd以高权限（系统或root）运行，并与内核驱动程序协同工作。
pppd程序还与LWIP（轻量级IP）项目一起使用，以在小型计算机上提供pppd功能。默认的lwIP安装和配置不易受此缓冲区溢出影响。但是，如果使用lwIP源代码并明确修改以在编译时启用EAP，则该程序可能容易受到缓冲区溢出的影响。
CVE-2020-8597 是 pppd 中的一个缓冲区溢出错误，起因是可扩展认证协议（EAP）数据包处理器中的逻辑缺陷。未经授权的远程攻击者向易受攻击的PPP客户端或服务器发送特制的EAP数据包，可能导致拒绝服务条件或任意代码执行。由于pppd与内核驱动程序协同工作，并且具有高权限（如设备或核心），任何代码执行也可能以相同权限执行。
漏洞发现者信息
由 IOActive 安全研究员 Ilja Van Sprundel 发现，关键问题是一个栈缓冲区溢出漏洞，该漏洞源于 pppd 应用程序的可扩展认证协议（EAP）模块解析器中的逻辑错误，该模块为 PPP 连接中的附加认证方法提供支持。
该弱点被追踪为 CVE-2020-8597，CVSS 评分 9.8，可被未经授权的攻击者利用，远程在受影响设备上执行任意代码并完全控制这些设备。
发现方式
此弱点归因于在将数据传输到内存之前验证输入大小的错误。由于数据大小验证不正确，随机数据可能被复制到内存中，从而可能触发数据库碎片化，并可能导致未经授权代码的执行。
该漏洞存在于 eap 解析代码逻辑中，具体是 eap.c 中的 eap_request() 和 eap_response() 函数，这些函数由网络输入处理程序调用。
如果 EAP 未启用或远端未通过密码或口令启动 EAP，就认为 pppd 是安全的，这种结论是错误的。因为未经身份验证的攻击者总是可以发送未经请求的 EAP 数据包来引发缓冲区溢出。
该漏洞已在点对点协议（PPP）守护进程（即 pppd）中发现。PPP 是一种第 2 层协议，用于通过拨号调制解调器、DSL 连接和许多其他物理网络（包括移动网络）建立连接。PPP 已被纳入并扩展为包含其他协议，例如用于虚拟专用网（VPN）提供加密连接的点对点隧道协议（PPTP）。
在这种情况下，SEI CERT 协作团队与发现此漏洞的安全分析师 Ilja Van Sprundel（IOActive）以及管理源代码的软件开发者 Paul Mackerras（OZlabs）合作，以轻松检查问题并找到解决方案。该问题涉及 pppd 源代码中的缓冲区溢出，原因是布尔表达式及其产生的条件语句存在基本缓冲区溢出。下面的语句可能被欺骗，允许未知长度的反馈并将其复制到栈缓冲区。这通常被称为帧溢出或栈缓冲区溢出。
if (vallen >= len + sizeof(rhostname)) { // 复制到缓冲区 rhostname
该漏洞的修复方法很简单：将上述语句改为下面的布尔逻辑。
if (len-vallen >= sizeof(rhostname)) { // 复制到缓冲区 rhostname
Paul 为此漏洞分配了 CVE-2020-8597，并继续修复他管理的源代码。修复该错误所需的系统更新很小，只需几行代码。然而，这种不安全的技术存在于数千个软件项目的库中。它已被超过 100 家提供网络接入设备的公司采用，涵盖从家用路由器到企业网络硬件。由于此弱点影响所有 PPP 客户端和服务器，也影响互联网服务提供商（ISP）。
发现时间
2020 年 3 月 4 日，CERT 协调中心（CERT/CC）的研究人员发布了关于点对点协议守护进程（pppd）版本 2.4.2 至 2.4.8 中关键漏洞的漏洞说明 #782301，披露归功于 IOActive 的 Ilja van Sprundel。
可能造成的损害
通过向易受攻击的 ppp 客户端或服务器发送未经请求的 EAP 数据包，未经授权的远程入侵者可以触发 pppd 机制中的内存损坏，这可能需要任意代码执行。
据研究人员称，点对点协议守护进程版本 2.4.2 至 2.4.8 —— 过去 17 年发布的所有版本 —— 都容易受到这个新的远程代码执行错误的影响。 以下一些常用且成功的 Linux 发行版已被报告受影响，其它许多项目也可能受到影响。
Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux
此外，许多其他包含 pppd 应用程序的易受攻击的应用程序和设备（下面列出了一些）数量可能也很大，为黑客提供了广泛的攻击面。
Cisco CallManager TP-LINK 产品 OpenWRT 嵌入式操作系统 Synology 产品
由于点对点协议守护进程（pppd）中的可扩展认证协议（EAP）数据包处理存在缺陷，未经身份验证的远程攻击者可能能够造成栈缓冲区溢出，从而可能允许在目标系统上执行任意代码。此漏洞是由于在将提供的数据复制到内存之前验证输入大小时出现错误。由于数据大小验证不正确，任意数据可能被复制到内存中，导致内存损坏，并可能导致执行不需要的代码。
利用技术
关键问题是一个栈缓冲区溢出漏洞，存在于 pppd 软件的可扩展认证协议（EAP）数据包解析器中，该模块为 PPP 连接中的附加认证方法提供支持。
为此，攻击者只需要通过直接串行链路、ISDN、以太网、SSH、socket CAT、PPTP、GPRS 或 ATM 网络，向易受攻击的 ppp 客户端或服务器发送未经请求的畸形 EAP 数据包。 此外，由于 pppd 通常以高权限运行并与内核驱动程序协同工作，该漏洞可能允许攻击者以系统或 root 级权限执行恶意代码。 选择的利用方法
使用远程代码执行方法利用易受攻击的客户端。远程代码执行（RCE）指的是网络入侵者能够在未经许可且不知晓机器位置的情况下，进入并对他人控制的设备进行修改。RCE 允许攻击者通过运行任意恶意软件来接管计算机或服务器。
我使用两台虚拟机在相同计算机上进行测试。一台作为服务器，一台作为客户端。为了连接虚拟机，我安装了 SSH。使用它们的 IP 地址，我将 Fedora 29 虚拟机作为服务器端，Kali Linux 虚拟机作为易受攻击的客户端端。按照说明，我设置了一个 pppoe-server。打开调试模式并设置日志文件，并将以下内容添加到日志文件 '/etc/ppp/pppoe-server-options'。然后通过输入 'sudo pppoeconf' 设置一个 pppoe-client。最后，使用 Python 代码可以利用易受攻击的客户端。此外，通过向易受攻击的 ppp 客户端发送未经请求的 EAP 数据包，远程攻击者可能导致 pppd 进程中的内存损坏，从而可能允许任意代码执行。
利用截图
对易受攻击客户端的 Ping 操作
安装 SSH 到服务器
获取客户端端的 root 访问权限
获取客户端 root 访问权限后
在客户端端启用 SSH
崩溃
结果
结论
GitHub 安全实验室的救援
当 Vijay Sarvepalli 研究 GitHub 最新的安全计划时，他想确定利用 GitHub 的 API 和 CodeQL 解决方案解决问题的机会，并使用代码向软件仓库用户提出修复。他联系了我们的政府安全负责人 Allan Friedman（美国商务部国家电信和信息管理局（NTIA）网络安全计划主任），后者组织了一系列组织，包括 GitHub，来创建软件物料清单（SBOM）。Allan 将 Vijay Sarvepalli 介绍给了 GitHub 负责保密的人员，他们让我与 GitHub 安全实验室负责人 Nico Waisman 取得了联系。
Nico 和他在 GitHub 安全实验室的国际团队迅速找到了一种方法，将他们的安全修补机制适用于这个问题。他们触发了一种自动的“机器人”技术，向所有受此错误影响的仓库的所有者发出通知。仓库所有者只需采取几个快速措施来修复和保护他们复制或分叉的 pppd 程序版本，从而修复该错误。这个社区倡议将我们带到了技术正在被修复的阶段。这提供了一种模块化、及时的方法来实现源代码的改进，以增强保护。在 GitHub 安全实验室自动更新后的四天内，1,896 个仓库的所有者收到了该错误的详细信息，并获得了只需点击几下即可修复的选择。其中至少 42 个仓库的所有者批准了自动补丁；另有 13 个确认问题已经修复。如果没有自动化，联系受影响仓库的所有者修复他们的应用程序将需要几天时间。
国防部的挑战以及 CERT 在软件未来中的角色
作为联邦资助的研究与开发中心（FFRDC），卡内基梅隆大学软件工程研究所（SEI）及其 CERT 部门不断面临美国国防部（DoD）在网络空间中的挑战。DoD CIO Terry Halvorsen，一位著名的网络安全倡导者，在 AFCEA 会议上表示，“网络防御行动和反制措施将在毫秒内发生”。这些理想的网络防御行动无法通过手动或繁琐的通信流程完成。它们必须通过软件交付，并尽可能实现自动化，以限制当前人机循环修补模型的问题。
在潜在威胁管理活动中，我们期望识别可以利用激励措施（例如与 GitHub 安全实验室的合作）来加速针对信息安全漏洞的源代码修补的情况。尽管我们理解这不能解决所有信息保护问题，也不能替代良好的编码方法，但我们确实意识到，错误往往在信息发布后才被发现。当信息渗透到我们的日常生活中时，只有及时识别漏洞，并且在可能的情况下通过自动化识别和响应，才能保护信息。
参考文献
• https://www.kb.cert.org/vuls/id/782301/ • https://thehackernews.com/2020/03/ppp-daemon-vulnerability.html • https://www.tenable.com/blog/cve-2020-8597-buffer-overflow-vulnerability-in-point-to-point-protocol-daemon-pppd • https://insights.sei.cmu.edu/cert/2020/03/security-automation-should-begin-at-the-source.html • https://packetstormsecurity.com/files/156802/pppd-2.4.8-Buffer-Overflow.html • https://www.drizgroup.com/driz_group_blog/what-is-remote-code-execution-attack-how-to-prevent-this-type-of-cyberattack • https://github.com/WinMin/CVE-2020-8597 • http://www.howtodoityourself.org/pppoe-server-how-to-do-it-yourself.html