README.md

CVE-2018-6924

The ELF parser of the syscall sys_execve performed insufficient validation on FreeBSD 10.4 through 11.2. This issue is a kernel DoS but could possibly utilized as kernel memory disclosure. It was anounced on 2018-09-12 and assigned CVE-2018-6924.

Description

Executing a malformed ELF file as an unprivileged user leads to a page fault in kernel. I suppose the ELF header parser (exec_elf64_imgact) gets confused and accesses memory based on the ELF header's pointers that is not available.

 Tracing pid 683 tid 100054 td 0xfffff80003568620
 pmap_map_io_transient() at pmap_map_io_transient+0x73/frame 0xfffffe002b59c3e0
 uiomove_fromphys() at uiomove_fromphys+0xcf/frame 0xfffffe002b59c450
 ffs_read() at ffs_read+0x269/frame 0xfffffe002b59c4e0
 VOP_READ_APV() at VOP_READ_APV+0x7c/frame 0xfffffe002b59c510
 vn_rdwr() at vn_rdwr+0x222/frame 0xfffffe002b59c5e0
 exec_elf64_imgact() at exec_elf64_imgact+0x274/frame 0xfffffe002b59c700
 kern_execve() at kern_execve+0x6de/frame 0xfffffe002b59ca40
 sys_execve() at sys_execve+0x4c/frame 0xfffffe002b59cac0
 amd64_syscall() at amd64_syscall+0xa38/frame 0xfffffe002b59cbf0
 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe002b59cbf0
 --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x800b49d0a, rsp = 0x7fffffffe7b8, rbp = 0x7fffffffe900 ---


 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address   = 0x30
 fault code              = supervisor read data, page not present

On my VM it seems to be a NULL pointer issue (NULL pointer in RCX).

 pmap_map_io_transient+0x73:     movq    0x30(%rcx),%rcx

As a conclusion, this yields at least to a local Denial of Service (kernel panic). I am not sure if you can tweak the pointer values and use them to read/probe kernel memory and may leak kernel memory to userland. If stars align and you get passed this read issue then you could get arbitrary writes in kernel spaces since there may be some writes based on pointers found the ELF header.

One more thing, readelf seems to be properly hardened. It does not crash while parsing this malformed ELF, it just complains that this ELF is damaged.