Can mprotect() be used to change the permissions of .rodata?
- Sections do not exist in the context of a running process, only segments.
mprotectcan be used to change the permissions of the pages thetextsegment is mapped to. Here is a tutorial on how to accomplish this: Writing a Self-Mutating x86_64 C Program- from the notes on the
mprotectmanual page: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.
Section information is stored in the section header table. The section header table is an array of section headers. The section header table is not mapped to any segment, and not parsed by the program loader. The loader uses segment information only when mapping a program into virtual memory.
Segments - not sections - have permissions, and these are stored in the segment's program header in the p_flags field. Program headers reside in the binary's program header table.
All of this is documented in chapters 4 and 5 in the System V ABI (generic).
In the output below, we can see the permissions associated with each segment under the flags column:
$ 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
.rodatasection in ELF files contains parts of the text segment that are not meant to be changed.
This is false. The entire text segment is Read/Execute.
By default, all pages from this section are read-only, and any attempt at modification will trigger a general protection fault.
This is false. Segments, not sections, are mapped to pages (hence the Align values) and have permissions (hence the Flags values).
More info can be found here:
- http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/
- https://lwn.net/Articles/631631/
- http://nairobi-embedded.org/040_elf_sec_seg_vma_mappings.html#section-segment-vma-mappings
From the manual:
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.
Here's a sample program to demonstrate.
#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;
}
Of course any data that you write to the page will remain in memory. Linux sees that the process is writing to a page that's currently mapped read-only and makes a copy. At the time of the write, the kernel doesn't distinguish this from copy-on-write after a process has forked. You can observe this by forking, writing in one process and reading in the other: the other process won't see the write since it's a write to the writing process's memory, not to the reading process's memory.
#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;
}
I suspect there are hardening patches that prevent a process from changing its own memory mappings, but I don't have one to offer.