基于GNU/Linux环境：静态链接libc与ret2libc攻击等技术问询

程序类型核心对比 #

静态PIE vs 动态PIE #

• 静态PIE：将所有依赖（含glibc）编译进单一二进制文件，属于位置无关可执行文件，加载时整个程序的代码段、数据段、栈等所有内存区域都会被ASLR随机化，无动态链接过程
• 动态PIE：仅编译自身业务代码，依赖系统中的动态glibc库，由ld.so在启动时完成链接；ASLR同样覆盖程序所有内存区域，包括glibc的加载地址

静态非PIE vs 动态非PIE #

• 静态非PIE：所有依赖编译进二进制，加载地址固定（通常为0x400000），完全无ASLR保护
• 动态非PIE：自身代码加载地址固定，但依赖的glibc库加载地址受ASLR随机化保护

核心安全问题解答 #

1. 静态链接libc是否可作为ret2libc攻击的防护措施？ #

是，但并非绝对防护。ret2libc攻击的核心是获取libc函数的固定内存地址：

• 如果是静态非PIE程序，libc函数地址完全固定，攻击者依然能构造ret2libc攻击
• 如果是静态PIE程序，整个程序的加载地址被ASLR随机化，攻击者无法提前预知函数地址，能有效阻断常规ret2libc；但如果程序存在信息泄露漏洞（比如泄露出某个静态嵌入的libc函数地址），攻击者仍可通过偏移计算得到其他函数地址发起攻击

2. 攻击者在动态链接程序中是否更容易获取目标libc函数的地址？若是，具体方式是什么？ #

是的，动态链接程序的特性给攻击者提供了更多获取libc地址的途径，常见方式包括：

• 利用信息泄露漏洞：比如程序输出栈上的返回地址（对应libc中某函数的地址）、全局偏移表（GOT）中的已解析条目，攻击者用泄露地址减去该函数在glibc中的固定偏移，即可算出libc基地址，进而得到所有函数的地址
• 读取GOT表：通过ROP gadgets读取程序的GOT表内容，获取已被动态链接器解析过的libc函数地址
• 泄露未初始化指针：程序中未初始化的全局指针可能指向libc内存区域，泄露该指针即可得到libc的加载地址线索

3. 攻击者所选函数（如system()）是否可能在静态链接二进制文件中不存在，但在动态链接文件中必然存在？ #

是的，原因如下：

• 静态链接时，GCC默认启用链接时优化（LTO）和垃圾代码消除（GC），如果程序没有直接或间接调用system()，链接器会将未被引用的libc函数从最终二进制中剔除，导致静态文件中无system()代码
• 动态链接程序仅在运行时依赖系统glibc库，不管程序是否调用system()，glibc本身都包含该函数，只要攻击者能拿到libc基地址，就能计算出system()的内存地址

内容的提问来源于stack exchange，提问作者mrn