一、研究幽灵漏洞及其变种(包括但不限于V1-V5)的攻击原理

1.1 基本漏洞原理(V1)

幽灵漏洞的基本原理是由于glibc库中的gethostbyname()函数在处理域名解析时,调用了__nss_hostname_digits_dots()函数存在缓冲区溢出漏洞。

具体来说,__nss_hostname_digits_dots()使用一个固定大小(1024字节)的栈缓冲区来存储解析后的数字和点字符。但在复制用户输入的域名字符串时,没有进行足够的长度检查,导致如果域名过长,就会发生栈缓冲区溢出。

攻击者可以构造一个超过1024字节的精心设计的域名字符串作为gethostbyname()的输入,在复制到栈缓冲区时就会覆盖相邻的内存区域,包括局部变量和返回地址。这样攻击者就可以控制程序执行流,实现任意代码执行。

2.1 变种攻击原理(V2-V5)

虽然V1漏洞被修补后,但研究人员发现__nss_hostname_digits_dots()函数对其他格式的字符串解析也存在缺陷,可以绕过补丁继续利用缓冲区溢出漏洞。主要变种包括:

V2: 带#字符的IPv6地址字符串

V3: 不合法的IPv4地址字符串

V4: 带%字符的域名字符串

V5: 以@@@开头的域名字符串

这些变种利用了函数在解析这些特殊格式字符串时的边界检查不严格,依然可以触发栈溢出。

以V5为例,攻击者可以构造一个类似"@@@###........###@@@"的域名字符串,在解析时会导致缓冲区溢出,从而劫持控制流。

2.3 攻击过程

无论是V1还是其他变种,攻击过程大致如下:

攻击者构造精心设计的、带有恶意荷载的域名/IP字符串

当gethostbyname()调用__nss_hostname_digits_dots()解析该字符串时，由于解析函数缺陷,发生栈缓冲区溢出,可控制返回地址

攻击者将返回地址覆盖为自己预先注入的shellcode地址

程序返回时将执行shellcode,攻击者获取目标系统控制权限

通过这种方式,攻击者可在目标系统上执行任意恶意操作,如安装后门、窃取信息等。

二、基于Github的幽灵漏洞尝试

通过git clone 下载github代码

make之后生成spectre.out

执行spectre.out，结果如图

┌──(itheima㉿itheima)-[~/john/spectre-attack]
└─$ ./spectre.out                          
Putting 'The Magic Words are Squeamish Ossifrage.' in memory, address 0x55cabec78008
Reading 40 bytes:
Reading at malicious_x = 0xffffffffffffdfa8... Unclear: 0xFE='?' score=999 (second best: 0xF2='?' score=999)
Reading at malicious_x = 0xffffffffffffdfa9... Unclear: 0xF6='?' score=999 (second best: 0xE7='?' score=999)
Reading at malicious_x = 0xffffffffffffdfaa... Unclear: 0xF3='?' score=999 (second best: 0xF2='?' score=999)
Reading at malicious_x = 0xffffffffffffdfab... Unclear: 0xFF='?' score=999 (second best: 0xFE='?' score=999)
Reading at malicious_x = 0xffffffffffffdfac... Unclear: 0xF4='?' score=999 (second best: 0xE0='?' score=999)
Reading at malicious_x = 0xffffffffffffdfad... Unclear: 0xE9='?' score=999 (second best: 0xE0='?' score=999)
Reading at malicious_x = 0xffffffffffffdfae... Unclear: 0xE7='?' score=999 (second best: 0xA5='?' score=999)
Reading at malicious_x = 0xffffffffffffdfaf... Unclear: 0xFF='?' score=999 (second best: 0xF2='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb0... Unclear: 0xF6='?' score=999 (second best: 0xF5='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb1... Unclear: 0x83='?' score=999 (second best: 0x7B='{' score=999)
Reading at malicious_x = 0xffffffffffffdfb2... Unclear: 0xFF='?' score=999 (second best: 0xFE='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb3... Unclear: 0xFD='?' score=999 (second best: 0xF2='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb4... Unclear: 0xF4='?' score=999 (second best: 0xF3='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb5... Unclear: 0xFD='?' score=999 (second best: 0xF2='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb6... Unclear: 0xFF='?' score=999 (second best: 0xF5='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb7... Unclear: 0xF5='?' score=999 (second best: 0xA8='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb8... Unclear: 0xFF='?' score=999 (second best: 0xFE='?' score=999)
Reading at malicious_x = 0xffffffffffffdfb9... Unclear: 0xFE='?' score=999 (second best: 0xF5='?' score=999)
Reading at malicious_x = 0xffffffffffffdfba... Unclear: 0xFF='?' score=999 (second best: 0xF5='?' score=999)
Reading at malicious_x = 0xffffffffffffdfbb... Unclear: 0xFE='?' score=999 (second best: 0xF6='?' score=999)
Reading at malicious_x = 0xffffffffffffdfbc... Unclear: 0xFF='?' score=999 (second best: 0xFD='?' score=999)
Reading at malicious_x = 0xffffffffffffdfbd... Unclear: 0xF2='?' score=999 (second best: 0xE9='?' score=999)
Reading at malicious_x = 0xffffffffffffdfbe... Unclear: 0xF5='?' score=999 (second best: 0xE0='?' score=999)
Reading at malicious_x = 0xffffffffffffdfbf... Unclear: 0xFE='?' score=999 (second best: 0xFD='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc0... Unclear: 0xFF='?' score=999 (second best: 0xF6='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc1... Unclear: 0xFE='?' score=999 (second best: 0xF6='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc2... Unclear: 0xF4='?' score=999 (second best: 0xE9='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc3... Unclear: 0xFF='?' score=999 (second best: 0xF3='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc4... Unclear: 0xE0='?' score=999 (second best: 0xA6='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc5... Unclear: 0xA7='?' score=998 (second best: 0x2E='.' score=998)
Reading at malicious_x = 0xffffffffffffdfc6... Unclear: 0xDF='?' score=999 (second best: 0xA7='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc7... Unclear: 0x90='?' score=999 (second best: 0x8F='?' score=999)
Reading at malicious_x = 0xffffffffffffdfc8... Unclear: 0xFF='?' score=999 (second best: 0x64='d' score=999)
Reading at malicious_x = 0xffffffffffffdfc9... Unclear: 0xEA='?' score=999 (second best: 0xDF='?' score=999)
Reading at malicious_x = 0xffffffffffffdfca... Unclear: 0xE0='?' score=999 (second best: 0x78='x' score=999)
Reading at malicious_x = 0xffffffffffffdfcb... Unclear: 0xF5='?' score=999 (second best: 0xDF='?' score=999)
Reading at malicious_x = 0xffffffffffffdfcc... Unclear: 0x8E='?' score=999 (second best: 0x7B='{' score=999)
Reading at malicious_x = 0xffffffffffffdfcd... Unclear: 0xF5='?' score=999 (second best: 0x92='?' score=999)
Reading at malicious_x = 0xffffffffffffdfce... Unclear: 0xF2='?' score=999 (second best: 0xE0='?' score=999)
Reading at malicious_x = 0xffffffffffffdfcf... Unclear: 0xE0='?' score=999 (second best: 0x92='?' score=999)

结果显示读取数据unclear，即无法读取，因为漏洞被发现之后，就有多种修复方式。

       主流Linux发行版厂商如Red Hat、Ubuntu、Debian等都发布了安全补丁修复。补丁修改了glibc库中处理主机名解析的__nss_hostname_digits_dots()等函数,增加了边界检查,修复了缓冲区溢出漏洞。

        glibc版本升级

        除了针对性补丁,升级到最新版本的glibc库(2.26及以上)也可以彻底解决这个漏洞。新版本重写了相关的解析代码,消除了缓冲区溢出的可能性。

         编译器保护措施

        现代编译器和操作系统默认启用了多种安全保护措施,如ASLR(地址空间布局随机化)、DEP(数据执行防护)、RELRO(重定位读写保护)等,这使得即使存在缓冲区溢出,也很难成功利用执行shellcode。