5 ms·

> no longer possible More difficult, but https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming is

by yuubi 12y ago

> no longer possible More difficult, but https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming is a thing.

brynet 12y ago
OpenBSD has switched it's platforms to using PIE (Position-independent Executables) by default. The 5.7 release will also introduce self-relocating static PIE. http://marc.info/?l=openbsd-cvs&m=141922027318727&w=2 http://marc.info/?l=openbsd-cvs&m=141922027318727&w=2
- chongli 12y ago
  A cursory Googling turned up this: http://flyer.sis.smu.edu.sg/trustcom11.pdf http://flyer.sis.smu.edu.sg/trustcom11.pdf I don't know whether it's practical or not but it's definitely possible.
  - comex 12y ago
    I think you're confusing the kernel and userland, as the post mentions that OpenBSD's kernel ASLR support (i.e. position independence) is currently limited. When it comes to userland, W^X is a much older feature, which OpenBSD pioneered, but which by now is essentially ubiquitous (except when a JIT is in use, e.g. in web browsers), along with ASLR. Such features have helped make exploits more difficult over time, but far from impossible - it all depends on the type of vulnerability, as well as things like how much interactivity exists between the attacker/the attacker's code and the target (potentially allowing em to gather data about ASLR, stack canaries, etc. before sending the final code execution bit). For example, web browsers are a very good case for the attacker, where not only is there a lot of interactivity in the form of JavaScript method calls, but a JIT usually ensures RWX pages exist; on the other side, an inetd server that spawns a new process for every request, with new ASLR offsets and stack canaries, would be pretty bad, since there is little interactivity. When it comes to the kernel, an important attack source is userland programs (already compromised or run by a malicious user in a multiuser system) trying to abuse the system call interface. In this case, not only is there a lot of interactivity (many system calls + complex low-level device drivers, if applicable + weird CPU features + high level of control over multiple cores/threads and timing + sharing the same CPU caches etc. with the kernel), on pre-Haswell x86-64 processors, there is actually no performant way for the kernel to prevent the memory of the currently running user process from being directly accessible from it (not executable as of Ivy Bridge though), making any kind of ASLR much less useful. So while kernels can and do get pretty far by having well-written code that avoids vulnerabilities, they usually only need to give an inch for userland to take a mile. There are, however, other, less favorable attack scenarios, e.g. remote attacks on network stacks, and in any case W^X can't hurt.

by yuubi 12y ago

> no longer possible More difficult, but https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming is a thing.

brynet 12y ago

OpenBSD has switched it's platforms to using PIE (Position-independent Executables) by default. The 5.7 release will also introduce self-relocating static PIE. http://marc.info/?l=openbsd-cvs&m=141922027318727&w=2 http://marc.info/?l=openbsd-cvs&m=141922027318727&w=2

chongli 12y ago
A cursory Googling turned up this: http://flyer.sis.smu.edu.sg/trustcom11.pdf http://flyer.sis.smu.edu.sg/trustcom11.pdf I don't know whether it's practical or not but it's definitely possible.
- comex 12y ago
  I think you're confusing the kernel and userland, as the post mentions that OpenBSD's kernel ASLR support (i.e. position independence) is currently limited. When it comes to userland, W^X is a much older feature, which OpenBSD pioneered, but which by now is essentially ubiquitous (except when a JIT is in use, e.g. in web browsers), along with ASLR. Such features have helped make exploits more difficult over time, but far from impossible - it all depends on the type of vulnerability, as well as things like how much interactivity exists between the attacker/the attacker's code and the target (potentially allowing em to gather data about ASLR, stack canaries, etc. before sending the final code execution bit). For example, web browsers are a very good case for the attacker, where not only is there a lot of interactivity in the form of JavaScript method calls, but a JIT usually ensures RWX pages exist; on the other side, an inetd server that spawns a new process for every request, with new ASLR offsets and stack canaries, would be pretty bad, since there is little interactivity. When it comes to the kernel, an important attack source is userland programs (already compromised or run by a malicious user in a multiuser system) trying to abuse the system call interface. In this case, not only is there a lot of interactivity (many system calls + complex low-level device drivers, if applicable + weird CPU features + high level of control over multiple cores/threads and timing + sharing the same CPU caches etc. with the kernel), on pre-Haswell x86-64 processors, there is actually no performant way for the kernel to prevent the memory of the currently running user process from being directly accessible from it (not executable as of Ivy Bridge though), making any kind of ASLR much less useful. So while kernels can and do get pretty far by having well-written code that avoids vulnerabilities, they usually only need to give an inch for userland to take a mile. There are, however, other, less favorable attack scenarios, e.g. remote attacks on network stacks, and in any case W^X can't hurt.