写点什么

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

  • 2022 年 9 月 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 年 9 月 23 日 14:084411

评论

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

新手模拟实现call和apply

前端树洞

大前端 js this JavaScrip

架构训练营——模块五作业——微博评论

开拓纪

架构训练营 模块五 微博评论

【架构实战营】第 5 模块作业

swordman

架构实战营

架构训练营模块五作业

Geek_e0c25c

架构训练营 架构实战营

go训练营第二周作业

spring-beans 注册 Beans(三) ConfigurationClassPostProcessor处理BeanDefinition流程

梦倚栏杆

微博评论高性能高可用计算架构设计

Hesher

架构 Architecture 架构实战营

【译】编写整洁 React 组件的简单小技巧

KooFE

大前端 React 6月日更 整洁代码

抖音封禁大量“卖惨带货”账号:应该严打恰烂钱的自媒体

石头IT视角

”微博评论“的高性能高可用计算架构

chenmin

kubelet之volume manager源码分析

良凯尔

Kubernetes 源码分析 kubelet Ceph CSI

# 架构实战营-作业5

大可

MySQL基础之四:排序、分组

打工人!

MySQL 6月日更

spring-beans 注册 Beans(二) springboot启动流程

梦倚栏杆

【LeetCode】左旋转字符串Java题解

Albert

算法 LeetCode 6月日更

微博系统中”微博评论“的高性能高可用计算架构

唐江

架构实战营

W1 linux操作系统基础

Kevin

运维 操作系统

spring-beans 注册Beans(一) 之问题场景复现

梦倚栏杆

区块链应用操作员国标出台 相关课程及教材正在编制中

CECBC

第五次作业

Geek_9cf7b5

中小银行数字化转型的路径和建议

CECBC

微博评论缓存架构设计

俞嘉彬

架构实战营

git stash误使用drop删掉本地保存,恢复代码一次记录

良知犹存

git

运动居然成了我的奢侈品?

悟空聊架构

程序员 程序人生 运动 6月日更

区块链拓宽实验艺术边界 新技术如何重塑现代美学想象?

CECBC

技术人员需要建立个人影响力么?

escray

学习 极客时间 朱赟的技术管理课 6月日更

☕【JVM技术探索】字符串常量池之G1回收期的驻留机制

洛神の殇

Java JVM 字符串常量池 6月日更

架构训练营 - 模块五作业(评论微博)

冬天的树

限流算法, 以 Golang 方式

hedzr

ratelimiter Go 语言 gin gin-middleware rate-limit

架构实战营模块6作业

En wei

架构实战营

开源的 OpenHarmony 是每个人的 OpenHarmony

开放原子开源基金会

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