Início / unix / Perguntas / 671908
Accepted
Shuzheng
Asked: 2021-10-06 00:46:12 +0800 CST

O interpretador `PT_INTERP` personalizado resulta em falha de segmentação?

  • 772

Depois de ler este artigo sobre como executar programas arbitrários alterando o PT_INTERPpara um interpretador personalizado, tentei experimentar isso localmente:

$ cat flag.c
#include <stdio.h>

int main(int argc, char **argv) {
    printf("Hello World!\n");
    return 0;
}
$ gcc -static flag.c -o flag
$ cat solution.c
const char interp_section[] __attribute__((section(".interp"))) = "./flag";
$ gcc -s -fno-ident -Wl,--build-id=none -Wl,-e,0 -static -nostdlib solution.c -o solution
$ ./solution
Segmentation fault
$ ./flag
Hello World!

Este PT_INTERPcabeçalho do programa contém um caminho, que é o caminho do interpretador (arquivo executável) em que nosso ELF será executado

Desde os solutionpedidos ./flagcomo seu interpretador, por que não ./flagroda e imprime a mensagem "Hello World", quando solutioné executado? Em vez disso, ocorre uma falha de segmentação, que é diferente do comportamento no artigo.

Como posso registrar e executar com sucesso um interpretador personalizado em PT_INTERP?

$ readelf -l solution

Elf file type is EXEC (Executable file)
Entry point 0x0
There are 4 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000000e0 0x00000000000000e0  R      0x8
  INTERP         0x0000000000000120 0x0000000000400120 0x0000000000400120
                 0x0000000000000007 0x0000000000000007  R      0x1
      [Requesting program interpreter: ./flag]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000000127 0x0000000000000127  R      0x1000
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp
   03
linux debian

1 respostas

  1. Best Answer

    Se você executar dmesg, deverá ver algo como

    (solution): Uhuuh, elf segment at 0000000000400000 requested but the memory is mapped already

    O motivo é que ambos flage solutiontêm um segmento em 0x400000.

    Uma maneira rápida de evitar isso é usar o tinyelf helloworldbinário como flag; não tem um segmento conflitante, e tudo funciona.

    Adaptando o exemplo do TinyELF, escreva isso para flag.c:

    #include <asm/unistd.h>

long syscall(long n,
             long a1, long a2, long a3, long a4, long a5, long a6);

void _start() {
  syscall(__NR_write, 1, (long) "Hello World!\n", 13, 0, 0, 0);
  syscall(__NR_exit, 0, 0, 0, 0, 0, 0);
}

long syscall(long n, long a1, long a2, long a3, long a4, long a5, long a6) {
  asm volatile ("movq %4, %%r10;"
                                "movq %5, %%r8;"
                                "movq %6, %%r9;"
                                "syscall;"

                : "=a"(n)
                : "a"(n), "D"(a1), "S"(a2), "d"(a3),
                  "r"(a4), "r"(a5), "r"(a6)
                : "%r10", "%r8", "%r9");
  return n;
}

    Construa isso da seguinte forma:

    gcc -nostartfiles -nostdlib flag.c -o flag

    Então o solutionbinário que você já tem funcionará.

    • 1

relate perguntas