4 ms·
This paper's thesis is that W^X does not work, and not because of any of the reasons presented in this thread: https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf
by sillysaurus3 10y ago
This paper's thesis is that W^X does not work, and not because of any of the reasons presented in this thread: https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf
The paper says that to bypass W^X protection, you can simply scan an executable for "the instruction you want to use, followed by a RET". The paper calls these "gadgets."
You can write any function you want by using these gadgets: simply call them. When you call a gadget, it executes the corresponding instruction, then returns. This allows you to write arbitrary functions, since real-world programs are large enough that they have a massive number of gadgets for you to choose from.
Can someone provide a counterargument?
- cosarara97 10y agoHow do you scan the executable when the memory layout is randomised? EDIT: https://news.ycombinator.com/item?id=11789653 https://news.ycombinator.com/item?id=11789653
- tptacek 10y agoWith any program behavior or bug that leaks memory layout. They're common.
- monocasa 10y agoVia what's known as an "information disclosure vulnerability". Basically the program somehow leaks what address something ended up at.
- cyphar 10y agoYou need to have a memory disclosure bug (they're very common). You don't even need to be able to read all of memory, you just need to know the start offset of where the library is loaded (if the library is from a distribution you can download it and figure out the ROP offsets using the library -- though apparently OpenBSD has defences against that too).
- admax88q 10y agoW^X isn't a solution for all memory corruption bugs. Only some. What this paper describes is called ROP (return oriented programming). Theo has a different patch in OpenBSD to help mitigate that by re-linking the libraries at system startup, randomizing the location of most gadgets.
- cyphar 10y ago> What this paper describes is called ROP (return oriented programming). Theo has a different patch in OpenBSD to help mitigate that by re-linking the libraries at system startup, randomizing the location of most gadgets. That's quite clever. By relinking I'm assuming that includes randomisation of the library objects? But that probably doesn't protect you if the program has a memory disclosure bug.
- icebraining 10y agoDiscussion of that paper on HN: https://news.ycombinator.com/item?id=1155954 https://news.ycombinator.com/item?id=1155954
- PeCaN 10y agoYeah. OpenBSD compiles everything as PIC, has ASLR, they were considering randomizing the locations of objects within libraries and executables (I think this was or is being implemented), as well as limited what you can do with a ROP exploit in the first place.
- ben_bai 10y agoAnd the newest SROP (Signal based Return Oriented Programming) mitigation. No misuse of the Signal Stack Frame possible.
- nickysielicki 10y agoThis is ROP, and W^X never was intended to stop this. Here's a link to a mailing list post that predates that paper by 3 years, which says exactly that. [1] [1]: https://groups.google.com/d/msg/lucky.openbsd.misc/FgDnMLqiQzg/YWBSuzBtlAwJ https://groups.google.com/d/msg/lucky.openbsd.misc/FgDnMLqiQ...
- cyphar 10y agoYou've just described ROP chains. While ROP chains allow you to bypass W^X they are not without their limitations. First of all, you need to have some sort of memory disclosure of the target process in order to figure out what gadgets exist. Secondly you need to have significant control of the stack (lots of empty space) to create a full ROP chain. Thirdly, not all processes have enough libraries loaded for you to do a nice ROP chain (I believe glibc gadgets are Turing complete but I think some other libcs are not).