Può essere usato mprotect () per modificare i permessi di .rodata?

2

La sezione .rodata nei file ELF contiene parti del segmento di testo che non sono destinate a essere modificate. Per impostazione predefinita, tutte le pagine di questa sezione sono di sola lettura e qualsiasi tentativo di modifica attiverà un errore di protezione generale. Linux syscall mprotect() è in grado di modificare le autorizzazioni di accesso per ogni pagina. Mi chiedo se la natura di sola lettura di .rodata sia applicata dal kernel in modo tale che syscalls come questo non possa modificare le sue autorizzazioni di accesso, o se il kernel imposta semplicemente le autorizzazioni predefinite per la pagina. Se il primo è vero, è possibile fare affidamento sul segmento dei dati di sola lettura per impedire anche a un programma compromesso di modificarlo in fase di runtime.

Il kernel di Linux applica la natura di sola lettura di .rodata ?

    
posta forest 29.11.2017 - 22:24
fonte

2 risposte

2
  • Le sezioni non esistono nel contesto di un processo in esecuzione, solo segmenti.
  • mprotect può essere utilizzato per modificare i permessi delle pagine a cui è mappato il segmento text . Ecco un tutorial su come ottenere questo risultato: Scrivere un auto-muting x86_64 C Programma
  • dalle note sulla % di manuale dimprotect :

    On Linux it is always permissible to call mprotect() on any address in a process's address space (except for the kernel vsyscall area). In particular it can be used to change existing code mappings to be writable.

Le informazioni sulla sezione sono memorizzate nella tabella delle intestazioni di sezione. La tabella di intestazione della sezione è una matrice di intestazioni di sezione. La tabella dell'intestazione della sezione non è associata a nessun segmento e non viene analizzata dal programma di caricamento. Il loader utilizza le informazioni sul segmento solo quando si associa un programma alla memoria virtuale.

I segmenti - non le sezioni - hanno permessi e questi sono memorizzati nell'intestazione del programma del segmento nel campo p_flags . Le intestazioni del programma risiedono nella tabella di intestazione del programma del binario.

Tutto questo è documentato nei capitoli 4 e 5 nel Sistema V ABI (generico) .

Nell'output seguente, possiamo vedere le autorizzazioni associate a ciascun segmento nella colonna flags :

$ readelf -l /bin/ls

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

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000019d44 0x0000000000019d44  R E    200000
  LOAD           0x0000000000019df0 0x0000000000619df0 0x0000000000619df0
                 0x0000000000000804 0x0000000000001570  RW     200000
  DYNAMIC        0x0000000000019e08 0x0000000000619e08 0x0000000000619e08
                 0x00000000000001f0 0x00000000000001f0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000001701c 0x000000000041701c 0x000000000041701c
                 0x000000000000072c 0x000000000000072c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000019df0 0x0000000000619df0 0x0000000000619df0
                 0x0000000000000210 0x0000000000000210  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .init_array .fini_array .jcr .dynamic .got

The .rodata section in ELF files contains parts of the text segment that are not meant to be changed.

Questo è falso. L'intero segmento text è Read / Execute.

By default, all pages from this section are read-only, and any attempt at modification will trigger a general protection fault.

Questo è falso. I segmenti, non le sezioni, sono mappati alle pagine (da cui i valori Align ) e hanno le autorizzazioni (da cui i valori Flags ).

Maggiori informazioni possono essere trovate qui:

risposta data 30.11.2017 - 01:01
fonte
1

Dal manuale :

On Linux it is always permissible to call mprotect() on any address in a process's address space (except for the kernel vsyscall area). In particular it can be used to change existing code mappings to be writable.

Ecco un esempio di programma da dimostrare.

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>

#define PAGE_SIZE 4096

const unsigned char rodata[3*PAGE_SIZE] = {1,2,3};

int main(void)
{
    printf("rodata = %p\n", rodata);
    uintptr_t page_base = ((uintptr_t)rodata / PAGE_SIZE + 1) * PAGE_SIZE;
    unsigned char *p = (unsigned char *)rodata + PAGE_SIZE;
    //*p = '!'; // this would cause a segfault
    puts("Before mprotect:");
    system("cat /proc/$PPID/maps");
    if (mprotect((void*)page_base, 1, PROT_READ | PROT_WRITE) < 0) {
        perror("mprotect");
        return 1;
    }
    puts("After mprotect:");
    system("cat /proc/$PPID/maps");
    *p = '!';
    return 0;
}

Ovviamente tutti i dati che scrivi nella pagina rimarranno in memoria. Linux vede che il processo sta scrivendo su una pagina attualmente mappata in sola lettura e ne fa una copia. Al momento della scrittura, il kernel non distingue questo da copia su scrittura dopo che un processo è stato biforcato. Puoi osservare questo attraverso biforcazione, scrittura in un processo e lettura nell'altro: l'altro processo non vedrà la scrittura poiché è una scrittura nella memoria del processo di scrittura, non nella memoria del processo di lettura.

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

#define PAGE_SIZE 4096

const unsigned char rodata[3*PAGE_SIZE] = {0};

void writer(char *p)
{
    if (mprotect(p, 1, PROT_READ | PROT_WRITE) < 0) {
        perror("mprotect");
        return 1;
    }
    puts("After mprotect:");
    system("cat /proc/$PPID/maps");
    *p = 1;
    printf("wrote %d\n", *p);
}

void reader(char *p)
{
    printf("read %d\n", *p);
}

int main(void)
{
    printf("rodata = %p\n", rodata);
    uintptr_t page_base = (((uintptr_t)rodata / PAGE_SIZE + 1) * PAGE_SIZE);
    volatile char *p = (volatile char *)page_base;
    //*p = '!'; // this would cause a segfault
    puts("Before mprotect:");
    system("cat /proc/$PPID/maps");
    if (fork() == 0) {
        writer(p);
    } else {
        sleep(1);
        reader(p);
    }
    return 0;
}

Ho il sospetto che ci siano patch indurenti che impediscono a un processo di modificare i propri mapping della memoria, ma non ne ho uno da offrire.

    
risposta data 30.11.2017 - 00:54
fonte

Leggi altre domande sui tag