深入研究：查找和修复高严重性的 libcurl/curl 漏洞

就在不久前，安全与发展界发布了一份公告，引起了安全与发展界的注意 curl 项目的首席开发者丹尼尔·斯坦伯格，他 丢掉了那封不幸的信 10月11日发布的新版本curl已发布，旨在解决两个高影响力的安全漏洞，他将其中一个漏洞描述为 “可能是长期以来最严重的curl安全漏洞”。

一个 验尸 在斯坦伯格的博客上指出，受影响的 curl 库版本容易受到基于堆的缓冲区溢出漏洞的影响，该漏洞与 2002 年以来使用的 SOCKS5 代理协议的遗留问题有关。

curl 作为命令行工具的使用可以追溯到 1998 年，因此被广泛认为是互联网的基础支柱。凭借如此悠久的历史和广泛的使用，这种依赖关系如果被发现易受攻击，可能会对总体网络安全产生持续影响。

该事件与美国的毁灭性Log4Shell攻击有相似之处 Log4j这是另一种脆弱的依赖关系，在将近两年后仍在被利用。
‍
>>> 立即使用我们的 curl Mission 测试您的知识！‍

漏洞：缓冲区溢出

该漏洞详见下文 CVE-2023-38545，并会影响 curl 版本 7.69.0，包括8.3.0。主要错误是基于堆的缓冲区溢出漏洞，初步报告指出，成功利用漏洞可能导致更具破坏性的远程代码执行 (RCE) 攻击。尽管这是威胁行为者可能的工作流程，但它是一个罕见的用例，而不是给定的。

也许缓解某些风险的唯一救济措施是恶意通信必须通过 SOCKS5 代理，这是一种相对罕见的部署。

与 curl 漏洞相比，让我们来看看这个缓冲区溢出解释器：

当 curl 被告知使用 SOCKS5 代理时，它将传递主机名并让代理对其进行解析。但是，如果主机名超过 255 字节的限制，curl 将在本地解析主机名（如以下代码片段所示）： 资源）。

如果客户端和代理之间的握手速度很慢，则可能会将长主机名而不是（较短的）解析地址复制到内存缓冲区中。分配的内存部分仅允许 255 字节的值，因此，如果它收到的值超过此限制，则数据将溢出内存缓冲区的边界。

>>> 在这篇文章中亲自尝试一下 可玩的任务!

缓冲区溢出是一种强大的攻击载体，在许多传统编程语言中很常见。在这个特殊案例中，尽管这种途径仍然不常见且不太可能，但利用漏洞在某些情况下以 RCE 的形式为更严重和更具破坏性的攻击铺平了道路。

如何缓解缓冲区溢出风险？

在此阶段，最高优先级的补救措施是将补丁应用于所有易受攻击的实例，并提醒您，curl 的使用非常普遍，可能不一定很明显或宣传您的系统组件包含正在使用的依赖项。在这种情况下，需要进行审计和后续补丁。

通常，缓冲区溢出缺陷可以通过使用内存安全语言来缓解缓冲区溢出缺陷，例如 生锈但是，就像像curl这样的庞大项目一样，移植到另一种语言或一时兴起重写是不切实际的。饰演 Stenberg 笔记 在讨论使用和支持更多用内存安全语言编写的依赖关系的可能性——或者逐步替换 curl 的部分内容的替代方案时—— “... 开发正在... 目前以近乎冰川般的速度进行，并以令人痛苦的清晰度显示了所涉及的挑战。在可预见的将来，curl 将继续使用 C 编写。”这不是一项小任务，其安全影响是巨大的。

安全错误可能而且将会发生，而且并非总是可以依靠扫描仪和测试来识别所有可能的攻击载体。因此，我们对抗这些漏洞的最大武器是致力于持续的安全意识和技能建设。
‍

想更多地了解如何编写安全代码和降低风险吗？

试试我们的 免费堆溢出挑战赛。

如果你有兴趣获得更多免费编程指南，请查看 安全代码教练 帮助您掌握安全编码最佳实践。