Node.js 8.15.1（LTS “Carbon“）安全发布详解：Slowloris 防御补全与 OpenSSL 1.0.2r 升级

Node.js 8.15.1LTS Carbon安全发布详解Slowloris 防御补全与 OpenSSL 1.0.2r 升级【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.orgNode.js 8.15.1 是发布于 2019 年 2 月 28 日的一次安全维护版本LTS Carbon 线核心包含两项 CVE 修复对 HTTP keep-alive 连接补齐server.headersTimeout超时收口阻断 Slowloris 慢速攻击CVE-2019-5737并将 OpenSSL 升级至 1.0.2r修复 0 字节记录填充预言机漏洞CVE-2019-1559。本文以 apps/site/pages/en/blog/release/v8.15.1.md 为骨架结合 Node.js 官网仓库中的安全公告与版本演化记录为你还原这次安全版本的完整技术脉络、受影响面判断与升级校验方法。本文对应的原始发布说明release/v8.15.1.md同一批次安全发布总览见 february-2019-security-releases.md。一、发布概况这是安全发布不是常规维护原文档开篇即明确This is a security release. All Node.js users should consult the security release summary at /blog/vulnerability/february-2019-security-releases/ for details on patched vulnerabilities.也就是说8.15.1 属于安全驱动的补丁版本而非常规 bugfix/feature 版本。这次发布与同一天2019-02-28发布的 Node.js 11.10.1Current、10.15.2LTS Dubnium、6.17.0LTS Boron共同构成 2019 年 2 月安全发布批次仓库中的总览文件 february-2019-security-releases.md 对四条活跃发布线逐一做了影响评估。本次 8.15.1 修复的 CVE 清单Node.jsSlowloris HTTP Denial of Service with keep-aliveCVE-2019-5737OpenSSL0-byte record padding oracleCVE-2019-1559与 2018 年 11 月批次的关系要理解这次修复需要回到 2018 年 11 月的安全批次。仓库中 release/v8.14.0.md 记录了 8.14.0 引入的两个关键防御服务端收到的 HTTP 头总大小不得超过8192 字节CVE-2018-12121服务端接收 HTTP 头时应用40 秒超时可通过server.headersTimeout调整头未在期限内收完时会在收到下一个 chunk 时销毁 socketCVE-2018-12122即 Slowloris 的初版修复。而 8.15.1 修复的 CVE-2019-5737正是 november-2018-security-releases.md 中所描述的CVE-2018-12122 的 keep-alive 变体当时 40 秒超时只覆盖了接收头部阶段keep-alive 模式下已建立的空闲连接没有持续应用该超时攻击者仍然可以通过慢速发送头部来长时间占用连接与资源。8.15.1 将server.headersTimeout设定的接收超时一致地应用到 keep-alive 模式下的连接补齐了这个缺口。二、CVE-2019-5737Slowloris keep-alive 变体的修复细节漏洞本质原文档 Notable Changes 中的描述http: Further prevention of Slowloris attacks on HTTP and HTTPS connections by consistently applying the receive timeout set byserver.headersTimeoutto connections in keep-alive mode. Reported by Marco Pracucci (Voxnest). (CVE-2019-5737 / Matteo Collina)Slowloris 是一种典型的低速率拒绝服务攻击CWE-400 非受控资源消耗攻击者与服务器建立 HTTP/HTTPS 连接后故意极慢地发送请求头让连接长期保持半完成状态从而持续占用服务端的 socket、线程与内存资源。单个连接影响有限但当攻击者并发建立大量此类连接时即可耗尽服务器资源导致拒绝服务。2018 年 11 月修复 CVE-2018-12122 时引入的 40 秒头部接收超时只针对新连接正在接收头部的场景而 keep-alive 模式下连接在完成一次请求后会被复用若攻击者在复用后的连接上重新开始慢速发送下一个请求的头原超时逻辑存在盲区。CVE-2019-5737 正是通过 keep-alive 连接复现慢速攻击。修复方式修复的核心思路是让server.headersTimeout设定的接收超时在 keep-alive 连接的整个生命周期内持续生效而不是只在首次头部接收阶段生效。这样无论连接处于首次请求还是 keep-alive 复用阶段只要头部迟迟未完整到达超时一到就会断开连接避免资源被无限期占用。从发布说明的 Commits 列表可以看到关键提交76d52c508a-http: prevent slowloris with keepalive connectionsMatteo Collinanodejs-private/node-private#162同一批次的其他发布线10.15.2、11.10.1也有完全一致的 Notable Changes 条目见 release/v10.15.2.md 与 release/v11.10.1.md说明该修复是在核心 http 模块中统一完成、再向各活跃发布线同步的。影响面与缓解根据 february-2019-security-releases.md 的评估Node.js 6Boron、8Carbon、10Dubnium、11Current全部受影响严重级别为LOW攻击潜力可被负载均衡器或其他代理层缓解——这提示生产环境中将 Node.js 服务置于反向代理/负载均衡之后的重要性。运维调优headersTimeout 与相关超时参数该修复引入了对server.headersTimeout语义的扩展理解这一参数族对运维 Node.js HTTP 服务至关重要server.headersTimeout服务端等待接收完整请求头的最长时间默认 60 秒在 8.x 修复后默认仍为 60sCVE-2018-12122 的 40 秒是其修复引入时的上下文表述实际生效默认值以 Node.js 文档为准。8.15.1 之后该超时对 keep-alive 复用连接同样生效。将其设为0可禁用仅在明确了解风险时使用。server.requestTimeout接收整个请求含 body的超时默认 300 秒。server.keepAliveTimeout空闲 keep-alive 连接在服务器关闭前的保持时间默认 5 秒Node.js 8.0.0 起引入。server.setTimeout()socket 空闲超时与上述参数配合使用。典型调优示例const http require(http); const server http.createServer((req, res) { res.end(ok); }); // 更激进的头部接收超时毫秒 server.headersTimeout 10000; // 10 秒内必须收完请求头 // 收紧空闲 keep-alive 连接保持时间 server.keepAliveTimeout 3000; // 3 秒 // 兜底socket 级空闲超时 server.setTimeout(30000, () { /* 超时处理 */ }); server.listen(3000);说明server.headersTimeout、server.keepAliveTimeout、server.requestTimeout等均为 Node.jshttp.Server实例属性Node.js 8.0.0 及之后版本提供本文仅给出以 8.x 为基准的通用写法精确默认值与版本行为请以目标 Node.js 版本的官方 API 文档为准。从源码结构看修复位于 Node.js 核心的lib/http.js与底层_http_server.js实现中本次发布说明的 Commits 指向 nodejs-private 私有仓库的 backport公开仓库中对应的长期实现可在lib/_http_server.js的超时处理逻辑中确认并通过测试用例覆盖 keep-alive 慢速请求场景。三、CVE-2019-1559OpenSSL 1.0.2r 与 0 字节记录填充预言机漏洞本质原文档 Notable Changes 中的描述deps: OpenSSL has been upgraded to 1.0.2r which contains a fix for CVE-2019-1559. Under certain circumstances, a TLS server can be forced to respond differently to a client if a zero-byte record is received with an invalidpaddingcompared to a zero-byte record with an invalidMAC. This can be used as the basis of a padding oracle attack to decrypt data.攻击机制可概括为攻击者向 TLS 服务器发送零字节记录若该记录携带无效 padding与携带无效 MAC服务器会给出可区分的不同响应攻击者利用这种响应差异构建padding oracle逐步恢复出被加密数据的明文。这属于密码学侧的 Oracle 攻击风险等级为MODERATE中等并非 Node.js 自身代码缺陷而是其捆绑的 OpenSSL 1.0.2 分支的漏洞。影响面为什么只有 6.x 和 8.x 需要升级根据 february-2019-security-releases.md 的影响评估Node.js 6Boron、8Carbon受影响使用 OpenSSL 1.0.2Node.js 10Dubnium、11Current不受影响使用 OpenSSL 1.1.x不存在该缺陷。也就是说CVE-2019-1559 只涉及仍捆绑 OpenSSL 1.0.2 的旧 LTS 线。8.15.1 将 OpenSSL 源码升级到1.0.2r提交d71517fd43-deps: upgrade openssl sources to 1.0.2rShigeki Ohtsu并在同批次为 6.x 提供 6.17.0 修复。关于Node.js 是否暴露该漏洞的谨慎态度原发布说明与总览公告都特别强调了一个事实边界We are currently unable to determine whether the use of OpenSSL in Node.js exposes this vulnerability. We are taking a cautionary approach and recommend the same for users.即当时无法确认 Node.js 对 OpenSSL 的使用方式是否真的会触发该漏洞但 Node.js 团队采取了宁可先修的保守策略并建议用户同步升级。这种表述本身就是安全发布的重要信息并非所有 CVE 都能立即确认可达性防御性升级同样合理。配套的 OpenSSL 构建修复升级 OpenSSL 源码并非单纯替换版本8.15.1 还包含若干配套的构建修复提交均为 Shigeki Ohtsu / Fedor Indutny61980dcbf9-deps: add -no_rand_screen to openssl s_clientbf287faf21-deps: fix asm build error of openssl in x86_win3222ec5feff0-deps: fix openssl assembly error on ia32 win322cc5e7f534-deps: copy all openssl header files to include dir6969fad7d6-openssl: fix keypress requirement in apps on win32这些提交解决了 Windows 32 位汇编构建错误、s_client 随机种子、头文件复制等跨平台构建问题确保 OpenSSL 1.0.2r 能在所有受支持平台含 Win32/ia32正确编译。四、发布物与校验文件清单与 SHASUMS 验证支持的平台产物8.15.1 提供了覆盖主流平台与架构的二进制与安装包对应nodejs.org/dist/v8.15.1/目录平台产物Windows32/64 位 Installer.msi、32/64 位 Binarywin-x86/node.exe、win-x64/node.exemacOS64 位 Installer.pkg、64 位 Binarydarwin-x64.tar.gzLinux32 位linux-x86、64 位linux-x64、PPC LE 64 位ppc64le、s390x 64 位、ARMv6/ARMv7 32 位、ARMv8 64 位arm64二进制AIX64 位 Binaryaix-ppc64.tar.gzSmartOS32/64 位 Binarysunos-x86、sunos-x64源码node-v8.15.1.tar.gz/.tar.xz下载安装示例# 以 Linux x64 为例 curl -O https://nodejs.org/dist/v8.15.1/node-v8.15.1-linux-x64.tar.xz tar -xf node-v8.15.1-linux-x64.tar.xz sudo cp -r node-v8.15.1-linux-x64/bin /usr/local/ node -v # v8.15.1使用 SHASUMS 校验下载完整性安全版本最重要的落地动作之一就是校验下载文件的哈希。发布说明提供了 PGP 签名的 SHASUMS 列表SHA256确保文件在分发过程中未被篡改。校验流程# 1. 下载发布说明中的 SHASUMS 文件与目标二进制 # 2. 计算本地文件的 SHA256 并与 SHASUMS 中的值比对 echo 16e203f2440cffe90522f1e1855d5d7e2e658e759057db070a3dafda445d6d1f node-v8.15.1-linux-x64.tar.gz | sha256sum -c - # 输出: node-v8.15.1-linux-x64.tar.gz: OK # 3. 可选用 PGP 公钥验证 SHASUMS 文件的签名 gpg --verify SHASUMS256.txt.asc SHASUMS256.txt说明上例中的哈希值取自 v8.15.1.md 的 SHASUMS 区块用于演示比对方法实际使用时请以官方发布页签名的 SHASUMS 文件为准并通过 PGP 验证签名以确保来源可信。五、升级建议与版本背景谁应该升级运行 Node.js 8.xLTS Carbon且暴露 HTTP/HTTPS 服务的部署应尽快升级至8.15.1以同时获得 Slowloris keep-alive 修复与 OpenSSL 1.0.2r 修复运行 Node.js 6.xBoron的部署升级至 6.17.0同一批次运行 10.x / 11.x 的部署若未升级到 10.15.2 / 11.10.1同样需要跟进 Slowloris keep-alive 修复CVE-2019-5737 影响所有活跃线。8.x 线的安全发布脉络从仓库的发布记录可以还原 8.x LTS 线的安全补丁演进8.14.02018-11-28引入 8KB 头大小上限CVE-2018-12121、40 秒头部接收超时CVE-2018-12122、URL 路径字符校验CVE-2018-12116、OpenSSL 1.0.2qCVE-2018-0734 / CVE-2018-54078.15.12019-02-28补齐 keep-alive 场景的头部超时CVE-2019-5737、OpenSSL 1.0.2rCVE-2019-1559。这种前序修复 后续变体补全的演进模式说明安全防御是一个持续迭代的过程攻击者会不断寻找修复的绕过路径如利用 keep-alive 复用维护方则需要持续收口。六、本文在 nodejs.org 仓库中的位置本发布说明是 Node.js 官网仓库博客体系的一部分位于 apps/site/pages/en/blog/release/v8.15.1.md与同类发布说明如 release/v8.14.0.md、release/v10.15.2.md共同归档于 apps/site/pages/en/blog/release 目录。这些文件经由 scripts/blog-data/generate.mjs 解析 frontmatter 生成博客元数据再通过 layouts/Blog.tsx 渲染为/blog/release/v8.15.1页面构成完整的发布说明阅读与检索体系。如需深入了解同批次安全公告的完整评估含每条 CVE 在各发布线的受影响明细可阅读 vulnerability/february-2019-security-releases.md关注 HTTP 超时防御体系的进一步演进可检索仓库中其他涉及server.headersTimeout的发布说明。【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考