ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

VLC 3.0.23 VP9 分辨率切换越界写崩溃 PoC 深度解析:64x64 → 64x8192 帧高突变触发陈旧 slice-thread entries 分配

VLC 3.0.23 VP9 分辨率切换越界写崩溃 PoC 深度解析:64x64 → 64x8192 帧高突变触发陈旧 slice-thread entries 分配 网络安全渗透测试示例工程【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址https://gitcode.com/GitHub_Trending/ex/exploitarium点击查看免费下载本篇技术指南围绕仓库内 vlc-vp9-reschange-crash-poc 这一紧凑型崩溃复现器展开它用纯标准库 Python 生成一个仅 405 字节的 VP9 IVF 媒体样本在 VLC 3.0.23Windows x64内置的 FFmpeg VP9 解码器中稳定触发 slice-thread 进度数组的越界零写。读完本文你将掌握该崩溃条件的完整成因链条sb_rows计算、陈旧分配与重置循环、样本的二进制结构与校验方式以及如何在本地用 VLC 二进制安全重放并解读崩溃码。概述一个 405 字节的崩溃复现器该 PoC 的核心是一份嵌入 Python 脚本中的 VP9 IVF 样本包含两帧关键数据第 1 帧64x64第 2 帧64x8192两帧保持相同的 VP9 tile-column 布局样本文件名中的tc0即 tile columns 0但第二帧的帧高从 64 突变到 8192。正是帧高变化而 tile-column 数量不变这一组合使 VLC 3.0.23 附带的 FFmpeg VP9 解码器在解码第二帧时命中了陈旧stale的 slice-thread 进度分配。复现器本身极小poc.py依赖 Python 标准库argparse、base64、hashlib、json、subprocess、pathlib无需任何第三方包生成样本后以 JSON 输出路径、SHA256 哈希与大小并可选地拉起本地 VLC 进程进行重放。需要强调的是README 明确标注其研究状态为不完整、持续进行中Research status: incomplete and continuing它定位为崩溃复现器而非完整利用链。漏洞机理slice-thread 进度数组的陈旧分配entries 数组按当前帧的超级块行数分配VP9 解码器以切片slice并行方式解码需要一个逐行记录各切片解码进度的数组README 中称为entries。关键点在于该数组的分配大小由当前帧的超级块superblock行数决定而超级块是固定64x64像素的块。对于64x64的首帧sb_rows (64 63) 6 1 entries allocation 1 * sizeof(atomic_int) 4 bytes即首帧只需要 1 个atomic_int4 字节的进度槽。对于后续的64x8192帧sb_rows (8192 63) 6 128新帧需要 128 个进度槽。分辨率改变为何不触发重新分配正常情况下分辨率变化会触发解码器内部状态的重置与重新分配但该路径的特殊之处在于当 tile-column 数量不发生变化时entries数组不会被重新分配仍然保留首帧按 1 行分配的 4 字节大小形成陈旧分配。这解释了必须同时满足帧高变化 tile-column 稳定才能复现的条件——若 tile-column 数量变化分配路径会被刷新越界条件也就不存在。重置循环对陈旧分配的固定模式零写解码新帧时VP9 的 slice-thread 重置循环按新帧的sb_rows逐行清零for (i 0; i s-sb_rows; i) atomic_store(s-entries[i], 0);新帧sb_rows 128而entries仍是首帧的 4 字节分配于是第二帧的解码过程变成一串 4 字节零写持续越过原本的 4 字节分配边界。在 Windows 上的 VLC 3.0.23 进程中具体结果取决于堆布局与运行时状态观测到的表现包括堆损坏终止0xC0000374与访问违规0xC0000005。从样本到崩溃IVF 容器与 VP9 帧结构生成后的样本可在本地直接按 IVF 容器格式解析验证解析逻辑与 poc.py 中内嵌样本的字节布局一致字段值说明文件总大小405 字节与 README 声明一致文件魔数DKIFIVF 容器标识版本 / 头长0 / 32 字节标准 IVF 头FourCCVP90VP9 编码容器宽 / 高64 / 64IVF 头保留首帧尺寸帧率rate1, scale1时间戳单位为 1s帧数2第 0、1 帧两帧在文件中的布局偏移从 IVF 头 32 字节后开始帧帧载荷大小时间戳数据偏移第 0 帧64x6494 字节032第 1 帧64x8192255 字节1138一个值得注意的细节IVF 容器头部仍记录64x64容器头不随帧更新真正的分辨率变化是编码在 VP9 帧的比特流内部的——两帧的未压缩头前缀0x82 0x49 0x83 0x42 ...一致差异体现在后续的帧尺寸与压缩头区域这与 README第二帧改变帧高、保持 tile-column 布局稳定的描述吻合。使用方式生成与校验样本生成默认的 IVF 样本输出vp9_reschange_64x64_to_64x8192_tc0.ivfpython poc.py生成到自定义路径python poc.py -o sample.ivf可选地拉起本地 VLC 重放python poc.py --vlc C:\Path\To\VLC\vlc.exe脚本在写出样本前会先做内嵌数据的完整性校验对 base64 解码后的字节计算 SHA256若与EXPECTED_SHA256不符则直接抛出RuntimeError(embedded sample hash mismatch)防止样本被篡改。预期哈希为F26BDEFBDFD0B44359E314E0BFDE7AEA979D29F80F598749DCCA68AB34F54649脚本输出结构化的 JSON{ sample: /abs/path/vp9_reschange_64x64_to_64x8192_tc0.ivf, sha256: F26BDEFBDFD0B44359E314E0BFDE7AEA979D29F80F598749DCCA68AB34F54649, size: 405, vlc: { ...: 仅指定 --vlc 时出现 } }CLI 参数一览见 poc.py 的argparse定义参数默认值说明-o, --outputvp9_reschange_64x64_to_64x8192_tc0.ivf样本输出路径--vlc无可选vlc.exe绝对路径用于本地重放--timeout8秒VLC 子进程超时超时判定为timeoutVLC 重放命令行参数逐一解析当传入--vlc时poc.py 的run_vlc()会构造一套适合无人值守重放的参数集并在 VLC 所在目录cwdstr(vlc.parent)启动子进程vlc.exe -I dummy --dummy-quiet --ignore-config --no-media-library --play-and-exit --run-time 2 --no-one-instance --no-qt-privacy-ask --no-qt-error-dialogs --no-crashdump --no-audio --vout dummy sample.ivf vlc://quit各参数作用参数用途-I dummy使用无界面 dummy 交互模块便于自动化--dummy-quiet抑制 dummy 模块输出--ignore-config忽略用户配置保证复现环境一致--no-media-library禁用媒体库避免干扰--play-and-exit --run-time 2播放后退出最多运行 2 秒--no-one-instance允许多实例不与既有 VLC 冲突--no-qt-privacy-ask/--no-qt-error-dialogs关闭隐私询问与错误弹窗防止进程挂起等待交互--no-crashdump关闭崩溃转储弹窗--no-audio/--vout dummy禁用音频、使用 dummy 视频输出聚焦解码路径vlc://quit播放结束后主动退出子进程结束后结果中会包含statusclean/crash:类型/nonzero/timeout、returncode与十六进制形式returncode_hex、elapsed耗时以及stdout_tail/stderr_tail各取末尾 2000 字符。崩溃观测与分类poc.py 内置了一张 Windows 崩溃码表用于把子进程返回码映射为可读类型十六进制返回码含义分类结果0xC0000005访问违规access violationcrash:access_violation0xC0000374堆损坏heap corruptioncrash:heap_corruption0xC0000409栈缓冲区溢出stack buffer overruncrash:stack_buffer_overrun返回码通过code32()做 32 位掩码归一化后参与分类返回码为0判定clean超时判定timeout其余返回码归为nonzero。README 还记录了本地插桩观测到的具体证据在plugins/codec/libavcodec_plugin.dll中陈旧重置循环位于 RVA0x698a5c以固定零写模式对陈旧entries分配执行写入。针对64x64 - 64x8192样本的直接存储追踪显示共129次entries存储其中127次越过请求的 4 字节分配其中114次越过分配器原始可用块raw usable block。可见越界写入规模远超分配本身且已穿透到堆块的可用区域之外。README 同时提醒在 Windows VLC 3.0.23 上进程的具体表现堆损坏终止或访问违规取决于堆布局与运行时状态并非每次重放都呈现同一崩溃码。测试目标、适用前提与研究边界README 声明该复现器针对以下环境验证VLC media player 3.0.23 for Windows x64解码模块plugins/codec/libavcodec_plugin.dllVP9 解码器源码谱系FFmpeg 4.4.x 的 VP9 解码器关键解码器行为是分辨率变化但不改变 tile-column 数量时entries分配保持陈旧。因此复现的有效性前提是目标 VLC 附带的 libavcodec 模块保持上述分配/重置逻辑且运行在 Windows 平台堆损坏/访问违规的观测结果依赖平台堆行为。仓库同时明确界定这是一个紧凑的崩溃复现器关于该原语primitive完整可利用性的研究尚不完整、仍在继续。请在自有的本地测试环境中运行——生成媒体文件的唯一用途是复现并研究解码器故障路径不应在生产环境或他人设备上使用。延伸阅读复现器本体poc.py原始研究说明vlc-vp9-reschange-crash-poc/README.md赞分享网络安全渗透测试示例工程【免费下载链接】exploitariumA single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and Ive always found this is the most efficient way.项目地址https://gitcode.com/GitHub_Trending/ex/exploitarium点击查看免费下载相关推荐Exploitarium 深度解析Pillow 12.3.0 ImageCms 可变 output_mode 绕过导致的堆越界写入 PoCExploitarium 深度解析Pillow 12.3.0 ImageCms 可变 output_mode 绕过导致的堆越界写入 PoC 本篇技术指南围绕网络安全渗透测试示例工程创维E900V21E 刷 Armbian 后有线网卡连不上3 步底包修复指南创维E900V21E 刷 Armbian 后有线网卡连不上3 步底包修复指南 创维 E900V21EAmlogic S905L2 芯片装了 Armbian嵌入式开发工具构建工具操作系统objdump DLX ELF 后端越界写漏洞 PoC 深度解析从 objdump -g 崩溃到计算器执行的完整复现指南objdump DLX ELF 后端越界写漏洞 PoC 深度解析从 objdump g 崩溃到计算器执行的完整复现指南 本文以开源仓库 objdump dlx网络安全渗透测试示例工程上一篇终极测评ast-grep多语言解析引擎如何实现极速代码搜索与重构下一篇Paper2GUI 代码覆盖率提高代码质量的测试策略创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表