Início / unix / Perguntas / 453749
Accepted
Evan Carroll
Asked: 2018-07-06 13:50:35 +0800 CST

O que define fs:[0x28] (pilha canário)?

  • 772

A partir deste post é mostrado que FS:[0x28]é um stack-canary. Estou gerando esse mesmo código usando o GCC nesta função,

void foo () {
    char a[500] = {};
    printf("%s", a);
}

Especificamente, estou recebendo esta montagem ..

    0x000006b5      64488b042528.  mov rax, qword fs:[0x28]                ; [0x28:8]=0x1978 ; '(' ; "x\x19"
    0x000006be      488945f8       mov qword [local_8h], rax
...stuff...
    0x00000700      488b45f8       mov rax, qword [local_8h]
    0x00000704      644833042528.  xor rax, qword fs:[0x28]
    0x0000070d      7405           je 0x714
    0x0000070f      e85cfeffff     call sym.imp.__stack_chk_fail           ; void __stack_chk_fail(void)
    ; CODE XREF from 0x0000070d (sym.foo)
    0x00000714      c9             leave
    0x00000715      c3             ret

O que está configurando o valor de fs:[0x28]? O kernel, ou o GCC está lançando o código? Você pode mostrar o código no kernel ou compilado no binário que define fs:[0x28]? O canário é regenerado - na inicialização ou no processo de geração? Onde isso está documentado?

linux security

2 respostas

  1. Best Answer

    É fácil rastrear essa inicialização, pois (quase) todos os processos stracemostram uma syscall muito suspeita durante o início da execução do processo:

    arch_prctl(ARCH_SET_FS, 0x7fc189ed0740) = 0

    É o que man 2 arch_prctldiz:

       ARCH_SET_FS
          Set the 64-bit base for the FS register to addr.

    Eba, parece que é disso que precisamos. Para encontrar quem chama arch_prctl, vamos procurar um backtrace:

    (gdb) catch syscall arch_prctl
Catchpoint 1 (syscall 'arch_prctl' [158])
(gdb) r
Starting program: <program path>

Catchpoint 1 (call to syscall arch_prctl), 0x00007ffff7dd9cad in init_tls () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00007ffff7dd9cad in init_tls () from /lib64/ld-linux-x86-64.so.2
#1  0x00007ffff7ddd3e3 in dl_main () from /lib64/ld-linux-x86-64.so.2
#2  0x00007ffff7df04c0 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff7dda028 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#4  0x00007ffff7dd8fb8 in _start () from /lib64/ld-linux-x86-64.so.2
#5  0x0000000000000001 in ?? ()
#6  0x00007fffffffecef in ?? ()
#7  0x0000000000000000 in ?? ()

    Assim, a base do segmento FS é definida pelo ld-linux, que faz parte de glibc, durante o carregamento do programa (se o programa estiver vinculado estaticamente, esse código será incorporado ao binário). É aqui que tudo acontece.

    Durante a inicialização, o carregador inicializa o TLS . Isso inclui alocação de memória e configuração do valor base do FS para apontar para o início do TLS. Isso é feito via arch_prctl syscall . security_init Depois que a função de inicialização TLS é chamada, o que gera o valor do protetor de pilha e o grava no local da memória, que fs:[0x28]aponta para:

    E 0x28é o deslocamento do stack_guardcampo na estrutura que está localizado no início do TLS.

    • 25

  2. O que você está vendo é chamado (no GCC) de Stack Smashing Protector (SSP) , que é uma forma de proteção contra estouro de buffer gerada pelo compilador. O valor é um número aleatório gerado pelo programa na inicialização e como o artigo da Wikipedia menciona, é colocado em Thread Local Storage (TLS) . Outros compiladores podem usar estratégias diferentes para implementar esse tipo de proteção.

    Por que armazenar o valor em TLS? Como o valor está localizado lá, seu endereço não é acessível pelos registradores CS, DS e SS, tornando muito difícil adivinhar o valor armazenado se você estiver tentando alterar a pilha de código malicioso.

    • 6

relate perguntas