CVE-2026-31431 注：本文章所有内容均无AIGC部分，部分内容摘自其他文章，AI在整个过程中只参与了部分逻辑讨论。 首先抛出一个问题，就效果而言，怎么会只有7分多？？？ CVE-2026-31431，这是一个利用 AF_ALG 与 splice() 组合实现 4 字节页缓存写入的认证擦除写入漏洞。一个 732 字节的概念验证代码可在 Ubuntu、Amazon Linux、RHEL、SUSE 上获取 root 权限。 如描述所言，这是一个提权漏洞。漏洞允许任何无特权本地用户在2017后的任意linux发行版中无条件提升至root权限，且过程无感，不触发任何本地检测。 行为上，它是通过对页缓存进行可控4字节的任意写入，setuid，目标很显然 su 收益最高。 路径上，由于是操作页缓存，且内核从未将受损页标记为脏页以进行回写，所以没有任何磁盘文件被修改，也因此常规的磁盘校验和无法检测此修改。 且，由于页缓存跨主机共享，所以同一漏洞原语可以突破容器边界，也就是说还有容器逃逸的事。 对比： 看到很多资料都会拿 DirtyCow 来做对比，我这边也聊聊吧 DirtyCow (CVE-2016-5195) 是所有备受关注的提权漏洞中很著名的一个，多次出现在很多渗透靶机中作为考题的存在，此漏洞逻辑上需要在虚拟内存子系统的写时复制路径中赢得条件竞争，所以需要多次尝试，且有系统崩溃的风险。并受特定版本限制，需要精确操控管道缓冲区。 CopyFail (CVE-2026-31431) 它属于一种逻辑缺陷，和前者的条件竞争无关，不需要任何时间窗口。 并且，可移植性超级强，因为是内核中的逻辑缺陷，所以完全相同的Payload可以在所有发行版和架构上跑通。无需针对性调整小参数，也无需编译，属于非常底层的一个漏洞。 利用及条件：此漏洞依赖于 python 作为操作窗口，但无需任何额外库，仅需标准库(os、socket、zlib)，且需要 3.10+ 版本需求(支持 os.splice)。 RootCause: 页缓存页面位于可写的 Scatterlist 和前面所描述的利用条件对应，该漏洞的核心是 splice() 函数。 Splice(): 内核中的一个系统调用，主要作用是在两个文件描述符之间移动数据，且过程完全在内核态完成，无需将数据拷贝到用户态，也就是 0拷贝操作。 主要是为了解决传统I/O的多次拷贝带来的性能开销问题，从结构上，他直接划掉了所有用户态的参与。 splice 不拷贝数据本身，它只在内核中拷贝数据的内存引用。指把 PageCache 中包含该数据的物理页引用传递给目标FD。过程中 0次CPU拷贝，只有两次上下文切换。 Linux规定，splice() 的两个文件描述符中，必须有一个是管道。用来承载那些指向实际数据的内存引用。 当然还有一个参与者 AF_ALG: 内核中的一种Socket地址簇(AddressFamily)，类似于 AF_INET(IPv4)或 AF_UNIX(本地套接字)。 在Linux 2.6.38引入，核心目的是为用户态程序提供一个标准、统一的接口，去直接调用内核态的 CryptoAPI。 这样说可能会觉得很突兀，那Linux为什么需要这个接口？ 硬件加速：现在CPU或者主板上一般都有专门的硬件加密引擎。内核驱动负责管理他们，用户态程序通过 AF_ALG 就可以享受硬件加速，就不需要自己写内联汇编或驱动通信了。 统一实现：内核里本身已经集成了很多密码学算法，通过 AF_ALG 暴露出来，可以让用户态省去链接巨大加密库的一个流程。 AF_ALG 的生命周期也和传统 Socket 有设计区别，我们常见的 Socket 认知是：Socket() -> Connect() -> Send()/recv()。但是 AF_ALG 采用了一种很奇特的 Two-Stage（两段式）架构，为了适配密码学操作中的"算法配置"与"数据处理"分离的特性。 ...
WriteUP-CVE-2018-1160
CVE-2018-1160 题材以及内容来源于pwnable，还算有意思的 然后本次我的测试及复现要特别感谢wetw0rk的思路参考。 由于文章复盘在我实际操作结束后一个月左右，所以我不会讲的太细，其中包括众多技术细节相关截图以及相关图表也没有得到保存 所以在这里我就口述主要思路以及我觉得可能需要做归档的部分了，需要详细了解漏洞细节的可以移步别的文章。 首先，目标是是netatalk的67256322aa5a1fff01de471d6787d1d862678746commit，已确定在这次commit之后已经得到修复，具体涉及版本号没去看，感兴趣的自己去了解，本文只做针对此次commit为基础的复现。 漏洞产生原因简述： git原文 CVE-2018-1160: libatalk/dsi: add correct bound checking to dsi_opensession The memcpy memcpy(&dsi->attn_quantum, dsi->commands + i + 1, dsi->commands[i]); trusted dsi->commands[i] to specify a size that fits into dsi->attn_quantum. The sizeof attn_quantum is four bytes. A malicious client can send a dsi->command[i] larger than 4 bytes to begin overwriting variables in the DSI struct. dsi->command[i] is a single char in a char array which limits the amount of data the attacker can overwrite in the DSI struct to 0xff. So for this to be useful in an attack there needs to be something within the 0xff bytes that follow attn_quantum. From dsi.h: uint32_t attn_quantum, datasize, server_quantum; uint16_t serverID, clientID; uint8_t *commands; /* DSI recieve buffer */ uint8_t data[DSI_DATASIZ]; /* DSI reply buffer */ The commands pointer is a heap allocated pointer that is reused for every packet received and sent. Using the memcpy, an attacker can overwrite this to point to an address of their choice and then all subsequent AFP packets will be written to that location. If the attacker chose the preauth_switch buffer, overwriting the function pointer there with functions pointers of his choice, he can invoke this functions over the network, Signed-off-by: Ralph Boehme <slow@samba.org> (cherry picked from commit b6895be) 所以，这里的触发点在于memcpy，由于DSI协议中用户对dsi结构体的内容控制边界没有得到妥善处理导致这里的memcpy的size args可以被控制 ...
Taint Analysis
深入研究基于Taint Analysis的自动化漏洞挖掘(Or 安全策略) 污点分析，一个算是很远古的手法，他的测试逻辑可谓毫无技术含量，但是他的出现也为AI自动化漏洞挖掘开了很大一块领地，直到今天，它依旧作为AI自动化漏洞挖掘的主要核心技术 回到技术本身，原则上它属于一个基于源码完整的Fuzzing框架，是一种追踪并分析污点信息在程序中流动的技术。在漏洞分析中，将所感兴趣的数据标记为污点数据(一般是程序的外部输入源)，然后通过跟踪和污点数据相关的流向，观察他们是否会影响关键的程序操作，引发未知行为的漏洞，然后根据具体行为，对漏洞链进行还原，即完成了一个漏洞的挖掘，整个过程只需要针对该框架进行设计Fuzzing流程。 所以，它本质上就是一种调试手段，而非攻击手段，属一种安全校验技术，与BROP(外部Fuzzing)完全相反，它属于内部Fuzzing，某些情况下需要对目标进行一定的修改，或运行在特定的系统上。 污点分析可以抽象成一个三元组： sources / 污点源(即直接引入不受信任的数据或者敏感数据到系统) sinks / 污点汇聚点(代表直接产生安全敏感操作(违反数据完整性)或者泄漏隐私数据到外界(违反数据保密性)) sanitizers / 无害处理(代表通过数据加密或者移除危害操作等手段使数据传播不再对软件系统的信息安全产生危害) 污点分析就是观测由sources引入的数据是否能够不经sanitizers而直接传播到sinks处，如果不能，说明信息流是安全的;否则，说明产生了数据流危险，具体体现为隐私数据泄漏或危险数据操作等安全问题 技术的处理过程可以分成三个阶段 识别合适的污点源和汇聚点 通常使用启发式的策略进行标记，例如把程序所有的外部输入的数据全部标记污点，保守的认为这些数据有可能包含恶意的攻击数据; 或者使用工具，利用其根据具体应用调用的API或者重要的数据类型，手工标记sources和sinks 其次就是使用统计或AI自动识别和标记(也是目前的大方向，大体结构已经成熟) 污点传播观测分析 观测分析中的显式流分析就是分析污点如何随程序中变量之间的数据依赖关系继承 隐式流分析是分析污点如何随程序中变量之间的控制依赖关系传播，也就是污点如何从条件指令传播到其所控制的语句 然后去同步观察污点扩散距离核心数据或危险函数的"距离"，发散分析，最后还原污点链 无害处理 污点数据在传播的过程中可能会经过无害化处理模块，具体是指sources经过该模块的处理后，数据本身不再携带铭感信息或者针对该数据的操作不会再对系统产生危害 所以，污点数据在经过这些无害化处理模块后，相应的sources标记可以被移除 所以从开发者角度来说，正确的使用无害处理可以降低系统中sources的数量 从分析角度来说，手动标记无害处理(例如无关函数，或无意义函数)可以让sources少走弯路，提高污点分析的效率，并且提高准确率 by the way. 加密库函数应该被识别成无害处理模块，一方面是由于库函数中使用了大量的加密算法，攻击者很难有效的还原计算密码的可能范围，另一方面是加密后的数据不再具有威胁性，继续传播sources没有意义(除非程序对其进行再解码并传播，所以可以在解密函数的范围重新对其打上sources，提高精确度) 具体数据流观测分析方法： 技术遵循链污染体系: 数据依赖传播(显式信息流) 污点传播分析中的显式流分析就是分析五点标记如何随程序中变量之间的(数据依赖关系)传播 即，我们标记变量x为污染点，在程序后续的逻辑中，如果变量x作为了别的表达式的操作数，那么操作结果也是污染的，以此类推，操作结果的后续逻辑会继续污染下去 相反，如果一个被污染的变量被赋值了一个常数，那么他就不再处于污染状态，所以转变成未污染 然后我们去相应的Sinks点进行观察，如果Sinks点的行为不能受程序输入的影响，那么就要检查Sinks点的条件值是否被污染 控制依赖传播(隐式信息流) 污点传播分析中的隐式流分析是分析污点标记如何随程序中变量之间的(控制依赖关系)传播，也就是分析污点标记如何从条件指令传播到其所控制的语句 如果一个控制表达式会受到某一个变量的影响行为，那么这个表达式受影响后的行为所操作的变量也属于污染变量 技术具体实现方法: 静态分析技术 指在不运行且不修改代码的前提下，通过分析程序变量间的数据依赖关系来检测数据能否从sources传播到sinks 静态分析的对象一般是程序的源码或中间表示，可以将对污点传播中显式流的静态分析问题转化为对程序中静态数据依赖的分析： 首先根据程序中的函数调用关系构建调用图(Call Graph,CG)，然后，在函数内或函数间根据不同的程序特性进行具体的分析，常见的显式流sources传播方式包括直接赋值传播、通过函数(过程)调用传播以及通过**别名(指针)**传播。 以所示的程序为例(直接copy文献的): 第 3 行的变量 b 为初始的污点标记变量,程序第 4 行将一个包含变量 b 的算术表达式的计算结果直接赋给变量 c.由于变量 c 和变量 b 之间具有直接的赋值关系,污点标记可直接从赋值语句右部的变量传播到左部,也就是上述 3 种显式流污点传播方式中的直接赋值传播. 接下来,变量 c 被作为实参 传递给程序第 5 行的函数 foo,c 上的污点标记也通过函数调用传播到 foo 的形参 z,z 的污点标记又通过直接赋 值传播到程序第 8 行的 x.f. 由于 foo 的另外两个参数对象 x 和 y 都是对对象 a 的引用,二者之间存在别名,因此,x.f 的污点标记可以通过别名传播到第 9 行的污点汇聚点,程序存在泄漏问题. ...