针对共享库的内存写保护

Question

我突然对某件事感到好奇。共享库，如glibc(在Linux中)、kernel32.dll(在Windows中)在进程之间物理上共享。但是，由于这些库位于用户虚拟内存地址空间中(映射)，我认为恶意进程可能会将共享库内存区域的访问属性更改为启用写操作，并将每个内容搞乱，从而使共享它们的所有其他进程崩溃。

我在Linux上做了下面的实验，系统没有崩溃。下面是我的测试源代码。

meltdown@ubuntu:/tmp$ cat a.c
#include <stdio.h>
#include <sys/mman.h>
#include <stdlib.h>
int g=0;
int main(int argc, char* argv[]){
    int* a = (int*)strtoul(argv[1], 0, 16);
    printf("globals : %p\n", &g);
    printf("a : %p\n", a);
    mprotect( a, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC);

int i=0;
for(i=0; i<0x3f0; i++){
    *(a+i)=0;
}

printf("done?\n");

while(1);
return 0;
}
meltdown@ubuntu:/tmp$ 

在我运行这个程序之前。我定位了libc.so.6的虚拟地址(我将内核设置为不使用ASLR)

meltdown@ubuntu:/tmp$ ldd a
linux-gate.so.1 =>  (0xb7fff000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7e37000)
/lib/ld-linux.so.2 (0x80000000)

在确认libc的地址后，我试图用NULL覆盖其中的一部分

meltdown@ubuntu:/tmp$ ./a 0xb7e37000
globals : 0x804a030
a : 0xb7e37000
done?
^C
meltdown@ubuntu:/tmp$ 

由于libc是在物理内存中共享的，所以如果我成功地覆盖了libc的内存，系统就会崩溃。然而，这个系统是很好的。我想这里发生了一些事情来阻止我想要的。

有人能解释一下为什么系统没有崩溃吗？提前谢谢你。

ps。我不是在说NX或DEP。请不要混淆。我说的是用完全访问权限覆盖共享库内存区域(例如根进程使用mprotect(.，.，PROT_READ|PROT_WRITE|PROT_EXEC).

Answer 1

共享库，如glibc(在Linux中)、kernel32.dll(在Windows中)在进程之间物理上共享。

正确，但与牛(复制在写入)属性。一旦您的进程写入共享页，它将获得不再与任何其他进程共享的页面副本。

我认为恶意程序可能..。搞乱每一项内容，使所有其他进程崩溃，共享它们。

不，它不能。它只能弄乱它自己的拷贝的内容，然后崩溃自己。