Stories
Slash Boxes
Comments

SoylentNews is people

RETGUARD: A Return-Oriented Programming Defense From OpenBSD

posted by Fnord666 on Wednesday September 13 2017, @06:03AM   Printer-friendly
from the going-back dept.

canopic jug writes:

Return-oriented programming (ROP) is now a common technique for compromising systems via a stack-smashing vulnerability. Although restrictions on executing code on the stack have mostly put an end to many simple stack-smashing attacks, that does not mean that they are no longer a threat. There are various schemes in use for defeating ROP attacks. A new mechanism called "RETGUARD" is being implemented in OpenBSD and is notable for its relative simplicity. It makes use of a simple return-address transformation to disrupt ROP chains to hinder their execution and takes the form of a patch to the LLVM compiler adding a new flag.

Original Submission

 
This discussion has been archived. No new comments can be posted.
RETGUARD: A Return-Oriented Programming Defense From OpenBSD | Log In/Create an Account | Top | 32 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by Virindi on Wednesday September 13 2017, @08:49PM (3 children)

    by Virindi (3484) on Wednesday September 13 2017, @08:49PM (#567452)

    Ignoring the write-prevention, yes. Presumably a software solution could do something similar, especially with kernel support; CET 'just' does something with page tables after all.

    You're right, not sure why I wasn't thinking about that. Clearly it is helpful to have the page containing the return address stack, have write protection against "normal" data write instructions.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by Wootery on Thursday September 14 2017, @08:14AM (2 children)

    by Wootery (2341) on Thursday September 14 2017, @08:14AM (#567691)

    I figure you could do a similar thing in software (i.e. block 'ordinary' instructions from accessing that stack) using syscalls, unless I'm missing something.

    • (Score: 2) by Virindi on Thursday September 14 2017, @09:25AM (1 child)

      by Virindi (3484) on Thursday September 14 2017, @09:25AM (#567706)

      How? It would have to be written to when you make a call. I am not aware of some easy mechanism to achieve this.

      I double checked the Intel reference manual, and attempting a call instruction when the next stack location is a non-write page results in a processor exception. So if you want to implement this in software, you'd have to have the OS deal with this exception and check on whether a call instruction was actually made (and not a normal memory write), make the push, then resume. This seems like a heck of a lot of overhead for every call!

      Or am I missing something?

      • (Score: 2) by Wootery on Thursday September 14 2017, @01:49PM

        by Wootery (2341) on Thursday September 14 2017, @01:49PM (#567793)

        You're right, there would be an awful amount of overhead there.

        I don't think there's any efficient mechanism to restrict access to a page to only certain functions.