如何在不链接libc.so的情况下访问段寄存器？

我正在尝试在 Ubuntu 20.10 上使用 NASM 版本 2.15.04 在 64 位程序集中编写一个简单的堆栈金丝雀。执行下面的代码会导致在使用命令进行汇编和链接时出现分段错误nasm -felf64 canary.asm && ld canary.o.

            global  _start

            section .text
_start:     endbr64
            push    rbp                     ; Save base pointer
            mov     rbp, rsp                ; Set the stack pointer
            call    _func                   ; Call _func
            mov     rdi, rax                ; Save return value of _func in RDI
            mov     rax, 0x3c               ; Specify exit syscall 
            syscall                         ; Exit

_func:      endbr64
            push    rbp                     ; Save the base pointer
            mov     rbp, rsp                ; Set the stack pointer
            sub     rsp, 0x8                ; Adjust the stack pointer
            mov     rax,  qword fs:[0x28]   ; Get stack canary
            mov     qword [rbp - 0x8], rax  ; Save stack canary on the stack
            xor     eax, eax                ; Clear RAX
            mov     rax, 0x1                ; Specify write syscall
            mov     rdi, 0x1                ; Specify stdout
            mov     rsi, msg                ; Char* buffer to print
            mov     rdx, 0xd                ; Length of the buffer
            syscall                         ; Write msg
            mov     rax, qword [rbp - 0x8]  ; Retrieve the stack canary
            xor     rax, qword fs:[0x28]    ; Compare to original value    
            je      _return                 ; Jump to _return if canary matched original
            xor     eax, eax                ; Clear RAX
            mov     rax, 0x1                ; Specify write syscall 
            mov     rdi, 0x1                ; Specify stdout
            mov     rsi, stack_fail         ; Char* buffer to print
            mov     rdx, 0x18               ; Length of the buffer 
            syscall                         ; Write stack_fail
            mov     rax, 0x3c               ; Specify exit syscall
            mov     rax, 0x1                ; Specify error code 1    
            syscall                         ; Exit

_return:    xor     eax, eax                ; Set return value to 0
            add     rsp, 0x8                ; Reset stack pointer
            pop     rbp                     ; Get original base pointer
            ret                             ; Return 

            section .data
msg:        db      "Hello, World", 0xa, 0x0
stack_fail  db      "Stack smashing detected", 0xa, 0x0

用GDB调试显示分段错误发生在第16行：mov rax, qword fs:[0x28].

─────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x40101b <_func+4>        push   rbp
     0x40101c <_func+5>        mov    rbp, rsp
     0x40101f <_func+8>        sub    rsp, 0x8
 →   0x401023 <_func+12>       mov    rax, QWORD PTR fs:0x28
     0x40102c <_func+21>       mov    QWORD PTR [rbp-0x8], rax
     0x401030 <_func+25>       xor    eax, eax
     0x401032 <_func+27>       mov    eax, 0x1
     0x401037 <_func+32>       mov    edi, 0x1
     0x40103c <_func+37>       movabs rsi, 0x402000
─────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "a.out", stopped 0x401023 in _func (), reason: SIGSEGV

然而，通过 libc 进行组装和动态链接nasm -felf64 canary.asm && ld canary.o -lc -dynamic-linker /usr/lib64/ld-linux-x86-64.so.2结果执行成功，不再导致分段错误。

使用 Radare2 比较最终的二进制文件表明，两个版本都以相同的方式组装问题指令：

0x00401023 64488b042528. mov rax, qword fs:[0x28]

在这两种情况下，GDB 还显示该指令执行时 FS 寄存器为 0x0000。

因此，无论二进制文件是否与 libc 链接，指令字节和 FS 寄存器都是相同的，并且代码没有使用 libc 中的外部符号。为什么链接 libc 会导致执行成功，而不链接 libc 会导致分段错误？是否有可能和/或如何在不链接 libc 的情况下实现这一点？

注意：此示例中堆栈金丝雀的相关性或需求不是问题的重点。

访问段寄存器没有问题，只需mov eax, fs。但是您想要做的是访问距 FS 段较小偏移的线程本地存储base，libc init 的东西会要求内核进行设置。

最简单的事情是使用正常的 RIP 相对寻址模式访问堆栈金丝雀，而不是相对于 FS 基础，就像 GCC 在针对其他 ISA 时所做的那样。仅当您想让其他漏洞更难到达金丝雀（并且使其地址可单独随机化）时，才需要 TLS。 （或者说，库代码可以访问它，而无需从 GOT 间接加载指针，而不是仅对主可执行文件中的代码有效。）

如果您想复制 GCC 的堆栈金丝雀代码，您当然可以进行与 libc 相同的系统调用来设置线程本地存储并使用它。

有趣的事实：sub rax, qword fs:[0x28]是比 XOR 更有效的检查金丝雀的方法 - 它可以与 JCC 宏融合到单个微指令中。这就是为什么当前的 GCC 改为使用sub. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90568- 在 GCC10+ 中修复。

我的 GCC 错误报告实际上包含了独立的微基准代码（以证明sub即使使用 FS：寻址模式也可以进行宏熔断）。

如果静态可执行文件中没有 libc，它会设置 FS 段，因此其基地址是缓冲区的地址，因此[fs: 0x28]将工作。这是 TLS 的基本形式。

global _start
_start:

cookie equ 12345
    mov  eax, 158       ; __NR_arch_prctl
    mov  edi, 0x1002    ; ARCH_SET_FS
    lea  rsi, [buf]
    syscall

    mov  qword [fs: 0x28], cookie

...


section .bss
buf:    resb 4096         ; fs.base will point at this buffer

如果内核启用wrfsbase对于用户空间使用，您可以使用wrfsbase rsi而不是进行系统调用。我认为最新的 Linux 内核（5.10）可能已经开始使用wrfsbase本身，但我不知道它是否允许用户空间使用它。

（它可能不会在每次使用时打开/关闭 FSGSBASE，因此内核使用意味着用户空间可以使用它；故障条件在手册中 https://www.felixcloutier.com/x86/wrfsbase:wrgsbase#64-bit-mode-exceptions不要提及特权级别，只提及 CPUID 功能位和 CR4 控制寄存器中的一位。并且仅在 64 位模式下；它会在其他模式下#UD，包括兼容模式。）