onars

9 ms·

1. 1.▲
   by onars 15y ago

   Using your terms, it is an implementation distinction as well. You install G-Free, call 'make' to build any software, it comes out gadget free. You delete G-free, call make, it comes out with gadgets. With our prototype implementation for
2. 2.▲
   by onars 15y ago

   That being said, I must say G-Free is practical by design, ie, it can realistically be implemented and used in a production environment, as opposed to many defense solutions (for ROP or other memory corruption attacks) which are just proof
3. 3.▲
   by onars 15y ago

   I am the author of the paper on G-Free. G-Free does not modify the assembler, or any other component on a system. It is a completely independent layer between the compiler and the assembler. And its performance overhead is indeed surprising
4. 4.▲
   by onars 15y ago

   It is true that code-reuse attacks have been around for some time, but Shacham's paper actually showed that you can make arbitrary --Turing complete-- computations with this approach, among other things. I think this alone is a good contrib