资讯动态

CPython 3.5.5rc1 安全补丁深度解析:sys.path[0] 回归漏洞、PyBytes_DecodeEscape 整数溢出与 libexpat 升级

发布时间:2026/9/10 13:39:59 来源:尧图企业网站定制
CPython 3.5.5rc1 安全补丁深度解析sys.path[0] 回归漏洞、PyBytes_DecodeEscape 整数溢出与 libexpat 升级【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython本文以 Misc/NEWS.d/3.5.5rc1.rst 这一份 Python 3.5.5rc1 版本2018-01-23 发布的变更日志为骨架逐条解析其中包含的安全修复sys.path[0]初始化回归漏洞bpo-32551、PyBytes_DecodeEscape整数溢出bpo-30657CVE-2017-1000158、两次嵌入式 libexpat 版本升级bpo-30947、bpo-31170以及 GC 潜在崩溃和二进制 plist 序列化修复。读完后你将理解 CPython 安全发布条目的组织方式、每条安全修复对应的源码位置以及这些修复在当前代码库中的落地形态。变更日志的组织方式Misc/NEWS.d 与 3.5.5rc1 条目Misc/NEWS.d/ 目录是 CPython 仓库存放各版本变更条目的位置目录内按版本号划分 rst 文件当前仓库中收录了 900 余个条目文件。每份文件对应一次具体发布文件头部用一组..指令描述元数据bpo对应的 bug 报告编号、date条目提交时间、nonce去重随机串、release date所属发布版本日期和section条目所属板块如Security、Library、Core and Builtins。以 3.5.5rc1.rst 为例该文件共收录 6 个条目其中 3 条标注section: Security其余分属Core and Builtins和Library板块——这与 3.5.5 作为 Python 3.5 分支安全维护发布的定位一致。理解这种一条 bug 一个条目、板块标注清晰的结构是阅读 CPython 安全公告的基础。sys.path[0] 回归漏洞bpo-32551 与导入位置安全事故回顾3.5.5rc1 中最重要的一条安全修复针对sys.path[0]的初始化。原文档的完整描述是bpo-29139 对sys.path[0]初始化所做的修改引发了一次回归暴露出sys.path在从 zip 文件、目录或其他导入位置执行__main__时初始化行为不一致的问题。这被视为潜在的安全问题因为它可能导致高权限进程在以往不会加载代码的场景下从用户可控的目录意外加载代码。修复后的行为是解释器现在一致地避免将导入位置的父目录加入sys.path并确保在把命令行中给出的导入位置插入sys.path时不会意外修改其他sys.path条目。原文档还特别交代了历史背景该问题最初作为 bpo-29723 针对 Python 3.6rc1 报告但当时遗漏了即将发布的 Python 3.5.4 同样受影响——这也是为什么它最终出现在 3.5.5 的安全发布中。当前代码库中的对应实现sys.path的计算逻辑如今集中在 Modules/getpath.py 中由自举 Pythonbootstrap Python在启动时计算解释器的默认路径。从源码结构看该文件明确以生成恰好预期的sys.path内容为目标文件第 122 行注释并在第 668 行设有UPDATE pythonpath (sys.path)的统一点集中更新最终的路径列表第 750 行还针对可执行文件目录出现在sys.path上这一历史怪癖QUIRK留有专门处理。bpo-32551 修复的核心诉求——插入命令行导入位置时不得连带修改其他条目——正对应这类集中化的路径写入逻辑把sys.path的构造收敛到单一代码路径正是消除 zip/目录/文件等不同导入场景下行为不一致的手段。PyBytes_DecodeEscape 整数溢出bpo-30657 与 CVE-2017-1000158漏洞条目原文变更日志原文只有一句话Fixed possible integer overflow inPyBytes_DecodeEscape, :cve:2017-1000158。Original patch by Jay Bosamiya; rebased to Python 3 by Miro Hrončok。PyBytes_DecodeEscape是 C 层的字节串反转义函数负责把形如b\x41\\n的转义序列还原为实际字节。它被 pickle 反序列化、C API 用户等多种路径调用因此其中的整数溢出属于可被恶意输入触发的安全问题当输入数据规模较大时长度相关的整型运算可能回绕进而引发缓冲区误分配。当前实现的关键防护点当前仓库中该函数实现在 Objects/bytesobject.c内部核心是_PyBytes_DecodeEscape2第 1176 行对外接口PyBytes_DecodeEscape在第 1290 行。从当前源码结构可以确认两点修复后的实现特征按显式长度分配输出缓冲区通过PyBytesWriter_Create(len)第 1182 行按输入长度len创建指针推进严格受s end边界约束不再依赖可能回绕的长度运算结果去决定写入上限八进制转义越界检测对\0\7开头的八进制转义代码逐位累加第 1221-1226 行并在第 1227 行检查c 0377即超过0o377/255 的八进制字面值一旦越界就通过first_invalid_escape_char出参记录首个非法转义字符及其位置随后PyBytes_DecodeEscape在拿到结果后第 1303-1304 行据此抛出异常而不是静默写入截断值。这套显式长度 转义值校验的组合就是 CVE-2017-1000158 修复在当前代码中的落点。需要注意该函数同时承担语义层面的校验如非法\x转义在 strict 模式下报错第 1250-1255 行安全修复与功能校验合并在同一实现中。嵌入式 libexpat 的两次连续升级bpo-30947 与 bpo-31170CPython 将 libexpat 作为第三方库嵌入仓库供xml.parsers.expat等模块使用。3.5.5rc1 日志中收录了两次连续的版本升级bpo-30947将嵌入的 libexpat 从 2.2.1 升级到 2.2.3目的是获取上游安全修复section: Securitybpo-31170再将 libexpat 从 2.2.3 升级到 2.2.4修复 UTF-8 输入下部分字符复制的问题对应 libexpat 上游 bug 115。两次升级相隔仅数月、版本只进了一到两个小版本号说明 CPython 对嵌入式 XML 解析器的维护策略是紧跟上游安全版本。查看当前仓库可以验证这条演进线Modules/expat/expat.h 中XML_MAJOR_VERSION/XML_MINOR_VERSION/XML_MICRO_VERSION宏声明的已是 2.8.4即后续主线早已将嵌入副本提升到远高于 3.5 分支的 2.2.4——阅读历史安全条目时要注意条目描述的是该发布时刻的状态而非当前代码库的状态。其他修复GC 潜在崩溃与二进制 plistGC 中因 tp_dealloc 未调用 PyObject_GC_UnTrack 导致的潜在崩溃bpo-31095Core and Builtins板块修复了一个垃圾回收期间的潜在崩溃当类型的tp_dealloc析构函数没有调用PyObject_GC_UnTrack()将自己从 GC 跟踪列表中移除时GC 可能访问已析构的对象而崩溃。该问题涉及 C 扩展扩展 CPython 时的对象生命周期纪律——凡是参与 GC 跟踪的类型其析构函数必须显式调用PyObject_GC_UnTrack()。当前仓库的 GC 模块实现位于 Modules/gcmodule.cC 扩展开发者可以结合该文件理解 GC 跟踪/解除跟踪的配对要求。二进制 plist 序列化的四类修复bpo-32072Library板块修复了plistlib对二进制 plist 格式bplist的处理共四类问题修复保存 bytearray 的问题相同对象identical objects只会被序列化一次相等引用equal references在加载时会还原为同一对象新增对递归自引用数据结构保存与加载的支持。当前仓库的 Lib/plistlib.py 保留了这一演进结果二进制写入路径以bbplist00魔数开头第 677 行对象写入由_write_object第 762 行分派、_write_size第 746 行负责长度编码读取侧以bplist00头识别二进制格式第 865 行。相同对象只保存一次、引用还原正是 bplist 格式基于对象引用表OID机制的固有特性这次修复让 Python 侧实现与格式规范对齐。对安全维护与代码阅读的启示从 3.5.5rc1.rst 这份发布日志可以归纳出 CPython 安全发布的三个特点安全条目有明确板块标注section: Security便于使用者快速判断一次发布是否值得在稳定分支上应用。3.5.5rc1 的 6 个条目中 3 个属于 Security回归安全漏洞会被回溯覆盖旧版本。bpo-32551 最初针对 3.6rc1 报告但 3.5.4 同样受影响的事实被补记最终在 3.5.5 统一修复——安全公告以受影响的所有分支为单位而非单一版本嵌入式第三方库的安全跟进是常规工作。libexpat 的 2.2.1 → 2.2.3 → 2.2.4 连续升级说明维护嵌入式副本的解释器项目需要持续关注上游 CVE 并小步跟进。结合源码验证时也要留意时间维度Objects/bytesobject.c中的转义校验逻辑、Modules/getpath.py 中集中化的路径计算、Lib/plistlib.py 的 bplist 读写都是这些 2018 年修复在后续主线中继续演进的产物与发布日志描述的修复目标一脉相承。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价