标签：Integer Overflow

共 2 篇相关文章

IT 累计浏览 1,935

Android libcutils库中整数溢出导致的堆破坏漏洞的发现与利用

文章从研究Android图形子系统时发现的一个整数溢出漏洞讲起，这个漏洞存在于libcutils库的native_handle_create函数中。作者龚广(@oldfresher)揭示了，当传入精心构造的numFds和numInts参数时，会导致堆内存分配大小计算溢出，进而引发堆破坏。具体来说，这个漏洞可通过Android图形系统的Binder接口（如IGraphicProducer的setSidebandStream）被低权限进程跨进程触发。更巧妙的是，作者构建了一条清晰的提权路径：从普通应用出发，必须按顺序依次注入mediaserver、surfaceflinger，最终目标是获得system_server的“半神”权限。摘要中点明了这一“三步走”策略的必要性——每一步获取的权限是攻击下一步的门票。文中还提及了攻击过程需克服的ASLR、SELinux以及je_malloc堆管理器等现实障碍，并以mediaserver注入为例，详细拆解了从控制Binder服务线程到最终代码注入的五个步骤。整篇文章不仅定位了漏洞根源，更完整呈现了从漏洞发现到实现高权限提权的复杂工程化利用全貌。

IT 累计浏览 2,390

小心 int 乘法溢出!

这篇讲的是 C/C++ 编程中一个隐蔽却危害巨大的陷阱：32 位 `int` 类型在进行乘法运算时可能发生的溢出问题。作者从一个实际场景切入——试图用 `malloc()` 分配 3000MB 内存时，代码 `mb * 1024 * 1024` 由于 `int` 只有 32 位，其计算结果早已溢出为负值 `-1073741824`。这个负值作为 `size_t`（64位系统中是64位无符号整数）参数传入 `malloc`，会被解释成一个天文数字（约 1844 亿亿），导致分配请求远超预期，引发程序崩溃或内存损坏。文章特别点明，这种错误非常具有迷惑性，因为无论操作系统是 32 位还是 64 位，`int` 通常是 32 位的。作者以亲身在 SSDB 项目中多次踩坑的经历作为佐证，强调了问题的普遍性与现实危害。核心告诫在于：当运算结果可能超出 `int` 范围，尤其是作为内存大小等参数时，必须显式地进行类型转换或选用合适的数据类型（如 `size_t`），以确保计算的正确性与安全性。对于处理大数据的系统开发者而言，这是个值得时刻警惕的细节。