0

我最近阅读了 D_FORTIFY_SOURCE 以及它对易受攻击的函数所做的更改。我想弄乱它，因此制作了一个小的测试二进制文件。

测试二进制源代码是：

  #include <stdio.h>
  #include <stdlib.h>
  //No ASLR/PIE
  //Enable FORTIFY
  //
  //
  //
  void shell()
  {
          system("sh");
  }
  
  int flag = 0;
  
  int main(int argc, char * argv[])
  {
          char buf [256];
          fgets(buf, sizeof(buf), stdin);
          printf(buf);
          if(flag)
          {
                  shell();
          }
  }

它并不打算做任何事情，只是为了尝试对 printf 的保护。

但是，当我编译程序时，它似乎并没有“强化”

确切的 gcc 命令是：

gcc fsFORTIFIED.c -o fsFORTIFIED -m32 -no-pie -D_FORITFY_SOURCE=2 -O2

我确保设置了优化标志，但标准的 printf 函数仍然存在。GDB 给出了 main 的汇编：

   0x080491c6 <+0>: lea    ecx,[esp+0x4]
   0x080491ca <+4>: and    esp,0xfffffff0
   0x080491cd <+7>: push   DWORD PTR [ecx-0x4]
   0x080491d0 <+10>:    push   ebp
   0x080491d1 <+11>:    mov    ebp,esp
   0x080491d3 <+13>:    push   esi
   0x080491d4 <+14>:    push   ebx
   0x080491d5 <+15>:    push   ecx
   0x080491d6 <+16>:    sub    esp,0x120
   0x080491dc <+22>:    call   0x80490e0 <__x86.get_pc_thunk.bx>
   0x080491e1 <+27>:    add    ebx,0x2e1f
   0x080491e7 <+33>:    mov    eax,gs:0x14
   0x080491ed <+39>:    mov    DWORD PTR [ebp-0x1c],eax
   0x080491f0 <+42>:    xor    eax,eax
   0x080491f2 <+44>:    mov    eax,DWORD PTR [ebx-0x8]
   0x080491f8 <+50>:    push   DWORD PTR [eax]
   0x080491fa <+52>:    push   0x100
   0x080491ff <+57>:    lea    esi,[ebp-0x11c]
   0x08049205 <+63>:    push   esi
   0x08049206 <+64>:    call   0x8049050 <fgets@plt>
   0x0804920b <+69>:    mov    DWORD PTR [esp],esi
   0x0804920e <+72>:    call   0x8049040 <printf@plt>
   0x08049213 <+77>:    add    esp,0x10
   0x08049216 <+80>:    cmp    DWORD PTR [ebx+0x2c],0x0
   0x0804921d <+87>:    jne    0x804923b <main+117>
   0x0804921f <+89>:    mov    eax,DWORD PTR [ebp-0x1c]
   0x08049222 <+92>:    sub    eax,DWORD PTR gs:0x14
   0x08049229 <+99>:    jne    0x8049242 <main+124>
   0x0804922b <+101>:   mov    eax,0x0
   0x08049230 <+106>:   lea    esp,[ebp-0xc]
   0x08049233 <+109>:   pop    ecx
   0x08049234 <+110>:   pop    ebx
   0x08049235 <+111>:   pop    esi
   0x08049236 <+112>:   pop    ebp
   0x08049237 <+113>:   lea    esp,[ecx-0x4]
   0x0804923a <+116>:   ret    
   0x0804923b <+117>:   call   0x80491a6 <shell>
   0x08049240 <+122>:   jmp    0x804921f <main+89>
   0x08049242 <+124>:   call   0x80492d0 <__stack_chk_fail_local>

在这里，我希望调用 printf_chk@plt，但它却调用了 printf@plt。为了确保这一点，我运行了程序，并给它输入了 %3$x，它运行良好而不是停止。

我的问题是，为什么 GCC 没有正确实现 D_FORITFY_SOURCE，即使设置了优化标志？

帮助表示赞赏

4

1 回答 1

1

确保-D_FORTIFY_SOURCE=2拼写正确。
（在这种情况下，它不是：-D_FORITFY_SOURCE=2是问题所在。）

与普通选项不同，GCC 无法为您捕获其中的拼写错误。

-Dfoo=bar只需定义一个预处理器宏（GCC 手册#D_FORTIFY_SOURCE 2），与文件顶部的完全相同。（-D是所有编译器都接受的标准编译器选项，而不仅仅是 GCC。）只有少数特殊的宏名称会影响像 stdio.h 这样的头文件。

对于像-fstack-protector-strong,-march=skylake或-fno-math-errno其他的选项，GCC 只接受它识别的有效选项。但是当然-Dfoo=bar对任何 foo 都有效，它只是不做任何事情，因为它不是 glibc 头文件在其#ifdefs 中使用的宏。

-D拼写正确；其余的选项就是定义的内容。

_在 ISO C 中，以1开头的全局范围名称保留给实现使用，这就是为什么定义_FORTIFY_SOURCE允许是特殊的。但 GCC 本身并不拒绝这样的名称。要让 GCC 做到这一点，它必须知道 glibc、MUSL 和“C 实现”的其他部分碰巧使用的所有名称，这会使处理这些头文件变得很痛苦。

脚注 1：reserved-names 规则没有那么广泛，我正在简化。

于 2020-10-20T11:41:55.430 回答