On 4/5/2016 9:32 AM, Philippe Meunier wrote:
Suppose instead the racket web server uses W^X: it has a writable-not-executable page somewhere, the JIT writes code into that page, then uses the mprotect system call to flip the page's permissions from writable-not-executable to executable-not-writable, and then the CPU can execute the code in that page. Now the pirate uses a buffer overflow somewhere in racket's code to try to write his own code into a page. If the page is already executable-not-writable then the pirate cannot write into it. If the page is writable-not-executable then the pirate can write into it but then the pirate cannot use the mprotect system call to change the page's permissions to make his code executable (because calling mprotect would require that the pirate can already execute code inside the server, which is precisely what the pirate is currently trying to achieve by using the buffer overflow to write his own code into the page; so the pirate has a chicken-and-egg problem: to have the CPU execute his own code the pirate needs to execute mprotect first, but to execute mprotect the pirate needs to already be able to execute code). So at best the pirate can trash the server's data and make it crash (because, well, you do have a buffer overflow somewhere in your code) but the pirate cannot get his own code to run inside the server so cannot own your computer. Hence why W^X is becoming popular as a way to mitigate the effects of security bugs (like buffer overflows).
Yes. However, W^X isn't panacea - overrun attacks against the CPU still can result in remote code execution. This kind of attack is difficult because it is limited to what code is already available in the application, and with the stack non-executable it is unlikely that a single overrun incident can produce a useful result ... but it still may be possible to craft a working multi-step attack. Address space randomizing helps against this kind of attack but W^X by itself does not.
IIUC, Racket's model is heap based and so Racket code is not vulnerable to stack based attack ... but C (or whatever) code in an FFI call certainly may be.
George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
