c-ares TCP UAF calc PoCExploitarium DNS解析器释放后使用漏洞GDB调试实录【免费下载链接】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/exploitariumExploitarium 仓库中的c-ares TCP UAF calc PoC针对 c-ares 异步 DNS 解析器的ares_getaddrinfo()路径完整复现了一个释放后使用Use-After-Free, UAF漏洞通过本地 DNS-over-TCP 服务器诱导 EDNS 重试再利用官方分配器钩子完成堆塑造最终在 GDB 中断点里看到 c-ares 跳转到攻击者控制的间接调用并弹出计算器作为代码执行证明。本文带你完整走一遍这次 GDB 调试实录。 先认识 PoCc-ares DNS 解析器 UAF 漏洞与 calc 载荷c-ares 是一个底层的异步 DNS 解析库被 Node.js、curl/libcurl、gRPC、Envoy、Wireshark 等大量软件依赖。本次研究针对的是它ares_getaddrinfo()接口在DNS over TCP EDNS 重试场景下的状态机缺陷触发路径ares_getaddrinfo()通道标志ARES_FLAG_EDNS | ARES_FLAG_USEVCDNS-only 查询漏洞形态陈旧stale查询状态在连接被 RST 重置后仍未清理后续查询清理阶段仍会消费它利用方式利用 c-ares 官方支持的ares_library_init_mem()分配器钩子塑造堆布局让陈旧指针指向一个伪造的跳表节点c-ares 调用自身析构函数时直接跳入proof_marker()该 PoC 是本地良性证明benign proof标记函数写入/tmp标记文件并尝试启动本地计算器不是面向所有 c-ares 用户的通用利用程序。 文件结构PoC 目录里有什么所有文件都在 c-ares-tcp-uaf-calc-poc/ 目录下文件作用poc/cares_tcp_uaf_calc_poc.c独立 C 证明框架环回 DoT 服务器 堆塑造 calc 载荷scripts/build_from_checkout.sh从指定源码 checkout 构建 c-ares 静态库并链接 PoCscripts/run_until_hit.sh重试循环直到堆布局命中控制流标记evidence/main-c93e50f3-gdb.txt上游 mainc93e50f3的 GDB 堆栈证据evidence/v1.34.6-gdb.txt官方 v1.34.6 版本的 GDB 堆栈证据evidence/local-verification.txt本地计算器与标记文件的验证记录两个版本均已验证命中上游main分支commitc93e50f3和最新官方版本v1.34.6commit3ac47ee4状态均为Unpatched未修复。 四步触发路径从 TCP DNS 查询到连接重置PoC 不是离线解析报文而是让 c-ares 发出真实的 TCP DNS 查询。整个攻击序列只有四步架设环回服务器PoC 在127.0.0.1启动一个 DNS-over-TCP 服务器见 cares_tcp_uaf_calc_poc.c 中的server_thread正常响应首包c-ares 查询example.com服务器接受 TCP 连接一次读取返回两个响应同一个 query id 先回FORMERR无 OPT 数据触发 EDNS 重试处理紧接着回一个同 id 的成功空响应重置连接接受重试写入后通过SO_LINGER(0)发送 RST之后 c-ares 内部清理仍会消费陈旧状态这正是 UAF 的窗口对象已死指针还在被用。 堆塑造用官方分配器钩子伪造尸体PoC 通过ares_library_init_mem()替换 c-ares 的 malloc/free核心手法tracked_malloc/tracked_free位于 cares_tcp_uaf_calc_poc.c跟踪所有144 字节的关键分配块释放时把陈旧指针所在的内存填成伪造的proof_slist_node结构其中parent-destruct指向proof_marker()随后 c-ares 执行node-parent-destruct(node-data)时指令指针RIP就落入了攻击者函数这解释了为什么它是代码执行而不只是一次崩溃——调用链完全经由 c-ares 自身的析构机制走通。 GDB 调试实录断点停在攻击者控制的间接调用上在 evidence/main-c93e50f3-gdb.txt 中GDB 在proof_marker处命中断点完整调用链一目了然#0 proof_marker (arg0x544440) at poc/cares_tcp_uaf_calc_poc.c:64 #1 ares_slist_node_destroy (node0x5444b0) at src/lib/dsa/ares_slist.c:461 #2 ares_query_remove_from_conn (query0x52daf0) at src/lib/ares_process.c:72 #3 ares_detach_query (query0x52daf0) at src/lib/ares_process.c:1474 #4 ares_free_query (query0x52daf0) at src/lib/ares_process.c:1512 #5 read_answers (conn0x52f830, ...) at src/lib/ares_process.c:656 #6 process_read (...) at src/lib/ares_process.c:688 #7 ares_process_fds_nolock (...) at src/lib/ares_process.c:214 #8 ares_process (...) at src/lib/ares_process.c:367 #9 main (...) at poc/cares_tcp_uaf_calc_poc.c:488 rip 0x401d8b proof_marker22逐帧解读这个堆栈帧 #0RIP 停在proof_marker22指令指针已被完全控制帧 #1ares_slist_node_destroy正在销毁一个陈旧跳表节点——被伪造的节点结构帧 #2–#4查询清理三连ares_query_remove_from_conn→ares_detach_query→ares_free_query即 UAF 被消费的确切时机帧 #5–#8read_answers→process_read→ares_process触发点正是处理 RST 后的那次读事件帧 #9main中的selectares_process事件循环v1.34.6 的堆栈evidence/v1.34.6-gdb.txt结构完全一致仅行号不同说明该路径在发布版中同样存在。️ 构建与运行最快看到计算器弹出的路径环境要求Linux 或 WSL、gcc、cmake、git。第一步构建。从官方仓库获取 c-ares 源码main分支或v1.34.6标签然后执行构建脚本它会生成静态libcares.a并以-O0 -g链接 PoC 二进制./scripts/build_from_checkout.sh /path/to/c-ares /path/to/build-dir ./cares_tcp_uaf_calc_poc第二步运行。控制流路径对堆布局敏感干净环境可能正常退出rc0所以官方提供重试脚本./scripts/run_until_hit.sh ./cares_tcp_uaf_calc_poc成功信号非常明确CARES_RCE_PAYLOAD_TRIGGERED runN rc77 c-ares control-flow payload reached pid...同时/tmp/cares_rce_proof_latest标记文件会被写入计算器启动顺序为WSL 下 Windows 计算器 →xcalc→gnome-calculator→kcalc。evidence/local-verification.txt 显示两个版本均run1 rc77一次命中连续 5 次重复测试也全部命中。 如果某次未命中不代表已修复——堆布局概率性偏移所致加大TRIES或用 GDB 证据模式复核即可。 影响面与缓解哪些应用依赖 c-aresc-ares 常以系统共享库、语言运行时内嵌依赖或包管理器传递依赖的形式存在实际影响面大于单个命令行工具。建议排查语言运行时Node.jsdeps/cares、Pythonpycares/aiodns/Tornado、Rustc-ares crate服务框架gRPC 客户端 DNS、Envoy Proxy 动态 DNS 集群桌面工具Wireshark 异步解析、curl/libcurl 构建排查命令ldd /path/to/binary | grep -i caresmacOS 用otool -L并strings搜索ares_getaddrinfo符号。缓解建议上游修复发布后重建所有静态消费者动态消费者需更新共享库并重启进程。短期可避免对不可信解析器强制 DNS over TCP、对解析器进程做沙箱隔离、监控 DNS 密集服务的异常退出。⚠️ 安全须知仅针对本地研究目标、自有系统或已授权环境运行此 PoC作者鼓励自行上报并认领 CVE截至发布时均未上报仓库 cves.md 已收录部分研究产出的 CVE 编号这是 Exploitarium 存档的一部分作者以公开 PoC 的方式吸引更多人进入安全研究领域严禁滥用本文基于 c-ares-tcp-uaf-calc-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 c-ares TCP UAF calc PoC：Exploitarium DNS解析器释放后使用漏洞GDB调试实录
c-ares TCP UAF calc PoCExploitarium DNS解析器释放后使用漏洞GDB调试实录【免费下载链接】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/exploitariumExploitarium 仓库中的c-ares TCP UAF calc PoC针对 c-ares 异步 DNS 解析器的ares_getaddrinfo()路径完整复现了一个释放后使用Use-After-Free, UAF漏洞通过本地 DNS-over-TCP 服务器诱导 EDNS 重试再利用官方分配器钩子完成堆塑造最终在 GDB 中断点里看到 c-ares 跳转到攻击者控制的间接调用并弹出计算器作为代码执行证明。本文带你完整走一遍这次 GDB 调试实录。 先认识 PoCc-ares DNS 解析器 UAF 漏洞与 calc 载荷c-ares 是一个底层的异步 DNS 解析库被 Node.js、curl/libcurl、gRPC、Envoy、Wireshark 等大量软件依赖。本次研究针对的是它ares_getaddrinfo()接口在DNS over TCP EDNS 重试场景下的状态机缺陷触发路径ares_getaddrinfo()通道标志ARES_FLAG_EDNS | ARES_FLAG_USEVCDNS-only 查询漏洞形态陈旧stale查询状态在连接被 RST 重置后仍未清理后续查询清理阶段仍会消费它利用方式利用 c-ares 官方支持的ares_library_init_mem()分配器钩子塑造堆布局让陈旧指针指向一个伪造的跳表节点c-ares 调用自身析构函数时直接跳入proof_marker()该 PoC 是本地良性证明benign proof标记函数写入/tmp标记文件并尝试启动本地计算器不是面向所有 c-ares 用户的通用利用程序。 文件结构PoC 目录里有什么所有文件都在 c-ares-tcp-uaf-calc-poc/ 目录下文件作用poc/cares_tcp_uaf_calc_poc.c独立 C 证明框架环回 DoT 服务器 堆塑造 calc 载荷scripts/build_from_checkout.sh从指定源码 checkout 构建 c-ares 静态库并链接 PoCscripts/run_until_hit.sh重试循环直到堆布局命中控制流标记evidence/main-c93e50f3-gdb.txt上游 mainc93e50f3的 GDB 堆栈证据evidence/v1.34.6-gdb.txt官方 v1.34.6 版本的 GDB 堆栈证据evidence/local-verification.txt本地计算器与标记文件的验证记录两个版本均已验证命中上游main分支commitc93e50f3和最新官方版本v1.34.6commit3ac47ee4状态均为Unpatched未修复。 四步触发路径从 TCP DNS 查询到连接重置PoC 不是离线解析报文而是让 c-ares 发出真实的 TCP DNS 查询。整个攻击序列只有四步架设环回服务器PoC 在127.0.0.1启动一个 DNS-over-TCP 服务器见 cares_tcp_uaf_calc_poc.c 中的server_thread正常响应首包c-ares 查询example.com服务器接受 TCP 连接一次读取返回两个响应同一个 query id 先回FORMERR无 OPT 数据触发 EDNS 重试处理紧接着回一个同 id 的成功空响应重置连接接受重试写入后通过SO_LINGER(0)发送 RST之后 c-ares 内部清理仍会消费陈旧状态这正是 UAF 的窗口对象已死指针还在被用。 堆塑造用官方分配器钩子伪造尸体PoC 通过ares_library_init_mem()替换 c-ares 的 malloc/free核心手法tracked_malloc/tracked_free位于 cares_tcp_uaf_calc_poc.c跟踪所有144 字节的关键分配块释放时把陈旧指针所在的内存填成伪造的proof_slist_node结构其中parent-destruct指向proof_marker()随后 c-ares 执行node-parent-destruct(node-data)时指令指针RIP就落入了攻击者函数这解释了为什么它是代码执行而不只是一次崩溃——调用链完全经由 c-ares 自身的析构机制走通。 GDB 调试实录断点停在攻击者控制的间接调用上在 evidence/main-c93e50f3-gdb.txt 中GDB 在proof_marker处命中断点完整调用链一目了然#0 proof_marker (arg0x544440) at poc/cares_tcp_uaf_calc_poc.c:64 #1 ares_slist_node_destroy (node0x5444b0) at src/lib/dsa/ares_slist.c:461 #2 ares_query_remove_from_conn (query0x52daf0) at src/lib/ares_process.c:72 #3 ares_detach_query (query0x52daf0) at src/lib/ares_process.c:1474 #4 ares_free_query (query0x52daf0) at src/lib/ares_process.c:1512 #5 read_answers (conn0x52f830, ...) at src/lib/ares_process.c:656 #6 process_read (...) at src/lib/ares_process.c:688 #7 ares_process_fds_nolock (...) at src/lib/ares_process.c:214 #8 ares_process (...) at src/lib/ares_process.c:367 #9 main (...) at poc/cares_tcp_uaf_calc_poc.c:488 rip 0x401d8b proof_marker22逐帧解读这个堆栈帧 #0RIP 停在proof_marker22指令指针已被完全控制帧 #1ares_slist_node_destroy正在销毁一个陈旧跳表节点——被伪造的节点结构帧 #2–#4查询清理三连ares_query_remove_from_conn→ares_detach_query→ares_free_query即 UAF 被消费的确切时机帧 #5–#8read_answers→process_read→ares_process触发点正是处理 RST 后的那次读事件帧 #9main中的selectares_process事件循环v1.34.6 的堆栈evidence/v1.34.6-gdb.txt结构完全一致仅行号不同说明该路径在发布版中同样存在。️ 构建与运行最快看到计算器弹出的路径环境要求Linux 或 WSL、gcc、cmake、git。第一步构建。从官方仓库获取 c-ares 源码main分支或v1.34.6标签然后执行构建脚本它会生成静态libcares.a并以-O0 -g链接 PoC 二进制./scripts/build_from_checkout.sh /path/to/c-ares /path/to/build-dir ./cares_tcp_uaf_calc_poc第二步运行。控制流路径对堆布局敏感干净环境可能正常退出rc0所以官方提供重试脚本./scripts/run_until_hit.sh ./cares_tcp_uaf_calc_poc成功信号非常明确CARES_RCE_PAYLOAD_TRIGGERED runN rc77 c-ares control-flow payload reached pid...同时/tmp/cares_rce_proof_latest标记文件会被写入计算器启动顺序为WSL 下 Windows 计算器 →xcalc→gnome-calculator→kcalc。evidence/local-verification.txt 显示两个版本均run1 rc77一次命中连续 5 次重复测试也全部命中。 如果某次未命中不代表已修复——堆布局概率性偏移所致加大TRIES或用 GDB 证据模式复核即可。 影响面与缓解哪些应用依赖 c-aresc-ares 常以系统共享库、语言运行时内嵌依赖或包管理器传递依赖的形式存在实际影响面大于单个命令行工具。建议排查语言运行时Node.jsdeps/cares、Pythonpycares/aiodns/Tornado、Rustc-ares crate服务框架gRPC 客户端 DNS、Envoy Proxy 动态 DNS 集群桌面工具Wireshark 异步解析、curl/libcurl 构建排查命令ldd /path/to/binary | grep -i caresmacOS 用otool -L并strings搜索ares_getaddrinfo符号。缓解建议上游修复发布后重建所有静态消费者动态消费者需更新共享库并重启进程。短期可避免对不可信解析器强制 DNS over TCP、对解析器进程做沙箱隔离、监控 DNS 密集服务的异常退出。⚠️ 安全须知仅针对本地研究目标、自有系统或已授权环境运行此 PoC作者鼓励自行上报并认领 CVE截至发布时均未上报仓库 cves.md 已收录部分研究产出的 CVE 编号这是 Exploitarium 存档的一部分作者以公开 PoC 的方式吸引更多人进入安全研究领域严禁滥用本文基于 c-ares-tcp-uaf-calc-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考