高品质的音视频能力是怎样的? | Qcon 全球软件开发大会·上海站邀请函 了解详情
写点什么

24 年了,终于有人发现 curl 的这个 Bug 了

  • 2022-09-23
    北京
  • 本文字数:2938 字

    阅读完需:约 10 分钟

24年了,终于有人发现curl的这个Bug了

这是一个关于 cookie、互联网代码和 CVE(通用漏洞披露)的故事。


本文最初发布于 Daniel Stenberg 的个人博客


curl 作者 Daniel Stenberg 近日在个人博客分享了一个存在 23.9 年的 curl 漏洞。curl 是常用的命令行工具,用来请求 Web 服务器,于 1997 年首次发行。


据 Stenberg 透露,这个漏洞是在 curl 发布后的第 201 天引入的,但是直到第 8930 天,漏洞才修复好。一个持续了 23.9 年的漏洞背后有着怎样的故事?


一切还得从 1998 年说起。

curl 4.9 与 cookie


1998 年 10 月,Stenberg 带领团队推出了 curl 4.9 版本。当时,听过或用过 curl 的人还少得可怜。几个月之后,curl 官网才宣布新版本的下载量达到了 300。那时,无论从何种意义上讲, curl 都还很小众。


curl 4.9 作为第一个带有 “cookie 引擎” 的版本,可以接收 HTTP cookie、解析、识别,并在后续的请求中把 cookie 正确地返回。在 curl 中,处理 cookie 的大部分代码都是 Stenberg 编写的。


那会,cookie 还没有明确的规范,仅有的一份描述 cookie 工作原理的规范,是一份由 Netscape 管理的文档cookie_spec (感兴趣的同学可以戳链接查看文档副本:https://curl.se/rfc/cookie_spec.html)。这份文档并不完善,有不少信息需要通过查看其它客户端才能了解到。


Stenberg 在实现处理 cookie 的代码时,就是参考了这份文档以及当时浏览器的大致处理方式。


此后十年,IETF(互联网工程任务组)一直在努力创建 cookie 规范,但均以失败而告终。这些早期 cookie 规范的创建者可能觉得,他们创建了标准,世界就会情不自禁地遵守它们,但事实并非如此。cookie 的特殊之处在于,有很多不同的作者、代码库和网站实现了它。因此,很难从根本上改变它们的工作方式。


直到 2011 年,cookie RFC 正式发布了,它记录并解释了 cookie 实际的使用方式,这可以说是真正意义上的 cookie 规范。Stenberg 本人也参与了规范的制定过程,并在其中阐述了自己的观点和意见。对于这份规范的内容,虽然 Stenberg 并不完全赞同,但与此前的各种 cookie 规范相比,cookie RFC 的确是一个巨大的进步。

cookie 双重语法带来的挑战


一开始,新的 cookie 规范并没有给 Stenberg 造成困扰,但很快,规范的特殊编写方式让 Stenberg 倍感头疼:它针对服务器如何发送 cookie 提供了一种字段语法,而针对客户端应该接受什么样的 cookie 提供了另一种语法。也就是说,同样的 cookie,需要两种语法。


这有两个很直接的缺点:


  1. 规范很难阅读。你很容易就停留在其中一种语法上,以为那就是适合自己用例的,但却没有意识到角色描述是错误的。

  2. 定义如何发送 cookie 的语法其实并不重要,因为如何接收和处理 cookie 都是由客户端决定的。现有的大型 cookie 解析器(浏览器)有一定程度的自由决定自己接受什么,所以没人注意,也没人关心服务器是否严格遵守了规范中的语法。与此同时,cookie 规范也在持续更新。从几年前开始,IETF 就一直在修订和更新 2011 年的 cookie 规范,计划将世界上一些已实际投入使用的 cookie 扩展添加到规范中。这项 cookie 规范更新工作被称为 6265bis。


curl 也同步进行更新,以确保符合 RFC 6265bis 草案版本的规定。


但是,双重语法仍然是 cookie 规范文档中悬而未决的问题。


随着时间的推移,cookie 的发展变得缓慢。在过去的几十年里,HTTP 规范也就更新了有限的几次,但值得一提的是,HTTP 服务器实现已经实施了更严格的解析策略:


如果传入的 HTTP 请求看上去“非法”或格式不正确,那么 HTTP 服务器就会提前拒绝,把它们挡在门外。对于请求中的控制代码尤其如此。如果你试图将一个包含控制代码(这里的控制代码指的是介于 1 到 31 之间的字节值,不包括 9,9 是 TAB)的请求发送到一个相当新的 HTTP 服务器,那么服务器很可能会拒绝,并返回 400 响应代码。从 2016 年 12 月发布的 2.4.25 版本开始,HTTP 服务器 Apache httpd 就默认启用了此行为。最新版本的 Nginx 似乎也是这样做的。


如果是现在设计 cookie,那么肯定会有所不同。


设置 cookie 的网站把 cookie 发送到客户端,对于其发送的每个 cookie,它都会设置多个属性。尤其是当需要客户端发回 cookie 时,它会设置匹配参数。


在 cookie 的这些参数中,其中有一个是 domain,客户端发送 cookie 时要匹配它。服务器www.example.com可以设置 cookie 的有效范围为整个example.com域,这时,客户端在访问second.example.com 时也会发送 cookie。也就是说,服务器可以将 cookie 设置为适用于“兄弟站点”。


值得一提的是,1998 年添加到 curl 中的 Cookie 代码在接受内容方面相当自由,当然,多年来也经过了不少调整和完善,不过它始终与现实世界的网站保持了兼容。对于那部分代码,Stenberg 修改的主要动力始终是为了使 curl 的 Cookie 处理方式与其他已有的使用 cookie 的代理保持基本一致,并可以互操作。

curl 的 Bug 详情与修复方案


2022 年 6 月底,Stenberg 收到了一份报告,报告怀疑 curl 中存在安全问题。正是这份报告促使 curl 发布了 CVE-2022-35252


事实证明,源于 1998 年的旧 cookie 代码,会接受包含控制代码的 cookie。控制代码可以是名称或内容的一部分,如果用户启用了“cookie 引擎”,那么 curl 就会存储那些 cookie,并在后续的请求中将它们发送回来。


例如,curl 会接受下面这样的 cookie:


Set-cookie: name^a=content^b; domain=.example.com
复制代码


^a 和 ^b 表示控制代码。由于域可以将 cookie 标记为适用于其他主机,、所以发送到域中所有主机的请求都会包含这个 cookie。


当 curl 将类似那样的一个 cookie 发送到 HTTP 服务器时,它的外发请求中会包含下面这样一个 header 字段:


cookie: name^a=content^b
复制代码


对此,Apache httpd 及其他服务器的默认配置都会返回 400。一个脚本或应用程序在收到这样的 cookie 后,如果后续的请求中还继续发送 cookie,就会遭到拒绝。


Stenberg 复盘后发现,cookie 规范 RFC 6265 5.2 节确实说了,客户端应该丢弃包含控制代码的 cookie,但这部分对用户来说理解起来比较难,需要对文档有深入的研究才能发现。此外,规范并没有提及“控制代码”或是字节值范围。


Stenberg 认为,要弄清楚主流浏览器是怎么做的还是比较容易的,因为它们的源代码很容易获得。事实证明,Chrome 和 Firefox 都已经忽略了包含以下任何字节的传入 cookie:


%01-%08 / %0b-%0c / %0e-%1f / %7f
复制代码


其中不包含 %09(TAB)和 %0a / %0d(行结束符)。


Bug 修复方面,Stenberg 表示,curl 的修复补丁处理方式非常简单:拒绝包含一个或多个禁用字节值的 cookie 字段。Stenberg 认为,这种修改基本是没有风险的。

写在最后


推算起来,有漏洞的代码从 curl 4.9 版本开始就一直存在,curl 7.85.0 版本才完成修复。整个历程有 8729 天(23.9 年)。也就是说,这个 Bug 是在项目发布的第 201 天引入的,到第 8930 天才修复。


Stenberg 认为,代码在发布时是没什么问题的,并且在用户的使用过程中,也基本没有产生什么问题。它的问题出在,HTTP 服务开始拒绝可能的恶意 HTTP 请求时。如此一来,这段代码就变成了一种拒绝服务,这或多或少会带来一些副作用。


或许,这个 Bug 诞生于 RFC 6265 发布之时。或许,它诞生于 HTTP 服务器开始拒绝这些请求时。不管怎样,这个 Bug 创造了一个新的项目记录:它是第四个被发现之前存在了 8000 多天的 Bug。

2022-09-23 14:085796

评论

发布
暂无评论
发现更多内容

架构师训练营第一期 - 第三周课后 - 作业一

极客大学架构师训练营

区块链到底是什么?它为什么如此受人关注

CECBC

区块链 金融

最完整的PyTorch数据科学家指南(1)

计算机与AI

学习 PyTorch

架构师训练营—第三周学习总结

Geek_shu1988

架构师训练营第 1 期 -- 第三周学习总结

发酵的死神

极客大学架构师训练营

架构师训练营第 1 期 week2

张建亮

极客大学架构师训练营

如何理解区块链行业的安全问题?

CECBC

区块链 人工智能 大数据

架构师训练营第三周命题作业

成长者

极客大学架构师训练营

spring-boot-route(一)Controller接收参数的几种方式

Java旅途

Java Spring Boot

架构师训练营第 1 期 -- 第三周作业

发酵的死神

极客大学架构师训练营

架構師訓練營第 1 期 - 第 02 周作業

Panda

架構師訓練營第 1 期

架构师训练营 1 期第 3 周:代码重构 - 总结

piercebn

极客大学架构师训练营

架构师训练营第 3 周作业

netspecial

极客大学架构师训练营

架构师训练营第一期 - 第三周课后 - 作业二

极客大学架构师训练营

区块链12年:应用在了哪些领域?

CECBC

区块链 教育 金融 物流

极客时间 - 架构师一期 - 第三周作业

_

极客大学架构师训练营 第三周

架构师训练营第三周学习总结

成长者

极客大学架构师训练营

为什么go中的receiver name不推荐使用this或者self

Gopher指北

后端 Go 语言

架构师训练营第 1 期 - 第三周学习总结

Anyou Liu

极客大学架构师训练营

架构师训练营—第三周作业

Geek_shu1988

第三周用组合设计模式编写程序

Geek_fabd84

【读书笔记二】《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》

Man

中台 分布式 研发管理

第三周总结

_

极客大学架构师训练营 第三周总结

LeetCode题解:242. 有效的字母异位词,数组计数,JavaScript,详细注释

Lee Chen

大前端 LeetCode

架构师训练营第 1 期 week2 总结

张建亮

极客大学架构师训练营

为啥你用@JsonFormat注解时,LocalDateTime会反序列化失败?

冰河

springboot LocalDateTime JsonFormat

Ui Automator 框架和Ui Automator Viewer你会用吗?附送「必备adb命令」拿走不谢 !

清菡软件测试

android

架構師訓練營第 1 期 - 第 02 周總結

Panda

架構師訓練營第 1 期

Linux忘记root密码怎么办

MySQL从删库到跑路

Linux 服务器 root密码 root

设计模式第三周作业「架构师训练营第 1 期」

天天向善

单例模式 组合模式

互联网上正规平台的辨别方法?被AG黑网投黑钱拿回的技巧方案

InfoQ_6b6a6317a692

24年了,终于有人发现curl的这个Bug了_语言 & 开发_平川_InfoQ精选文章