Scribd
Upload
75 views11 pages

Brad Spengler / Grsecurity

The document discusses several strategies for hardening the Linux kernel against attacks. It recommends (1) removing information leaks, disabling execution of code from kernel memory, and protecting sensitive kernel data. It also suggests (2) adding protections like Address Space Layout Randomization (ASLR) and enforcing control flow integrity to prevent exploits. Finally, it states (3) the kernel needs to be secured through techniques like removing read-write-execute permissions from memory and protecting against invalid memory accesses from userland.

Uploaded by

Johnny Cow
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
75 views11 pages

Brad Spengler / Grsecurity

The document discusses several strategies for hardening the Linux kernel against attacks. It recommends (1) removing information leaks, disabling execution of code from kernel memory, and protecting sensitive kernel data. It also suggests (2) adding protections like Address Space Layout Randomization (ASLR) and enforcing control flow integrity to prevent exploits. Finally, it states (3) the kernel needs to be secured through techniques like removing read-write-execute permissions from memory and protecting against invalid memory accesses from userland.

Uploaded by

Johnny Cow
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Brad Spengler / grsecurity

Raise Aim

TCO

o Total cost of ownership (Dave Aitel)

for skilled attackers unpredictable & hostile environment

o APT these days

Create
o ASLR

o Infoleak removal
o No RWX in memory or on disk

Often,

Access Control only plays a role postexploitation


o A last line of defense

Post-exploitation,

permanence Develop more complex exploit that plays along with published SELinux policies? Attack that new perf_counter system call completely unmonitored by SELinux?

an attacker wants

Vmsplice Tee/splice Perf_counter Move_pages

Aout Brk

loader

Mremap Pipe

ELF

loader

Etc

Lots of attention paid to hardening userland Nearly no mainline attention to the kernel What will attackers target? Enlightenment

o Disables SELinux, TOMOYO, IMA, AppArmor, all other

LSMs o Grants full root, full capabilities, works in Xen o Upcoming LXC/OpenVZ support, since:

If you are inside a user_namespace your capabilities will only be good for manipulating other objects [] that you have created after you entered the user namespace

Only

public exploits produce a change in public perception of security Kernel security wasnt suddenly horrible in 2009, I simply showed how horrible its always been Unlike with Tavis v. Microsoft, I received no threats from Linux vendors
o Although

In

the end, stronger SELinux protections, stronger mmap_min_addr, much higher user awareness

Remove

infoleaks

o Symbol information
o Slabinfo o PAX_USERCOPY

Remove

RWX from kernel Protect sensitive data


o Constify function pointers!

o IDT/GDT/syscall table/etc
o Vsyscall shadow table (see sgrakkyus remote

SELinux-disabling exploit)

Protect

against invalid userland memory accesses in general Make refcount overflows unexploitable
o Currently equivalent to use-after-free

kmalloc(sizeof(somestruct)

* attacker_len)

o See recent ethtool get_rxnfc() vulnerability

Basically,

secure the kernel! Your super finegrained security systems will thank you

PAX_UDEREF
o Found likely oldest Linux bug ever (>= v0.01) o vgaarb direct userland dereference o NVIDIA direct userland dereference

PAX_KERNEXEC
o Enlightenment wont run (nor (all?) other memory-

corruption based public exploits)

PAX_USERCOPY
o Found heap-based ~64kb infoleak

PAX_MEMORY_SANITIZE
o Found use-after-free in CONFIG_NO_BOOTMEM

ASLR

is a simple, useful technique

o Ineffective in several cases (ones mainline

doesnt handle properly already, and others) o Statistics-based security


Deterministic The

control flow integrity

o So long ret2libc/ROP/any other name

syscall table is protected how about those page tables?

Into

the lions den!

You might also like