0

I was wondering why storing entire program in ROM doesn't prevent buffer-overflow, return-to-libc attacks ?

Is the code still loaded in RAM before executing which makes it vulnerable to control-flow attack ? (if that's the case why aren't code pages marked as read-only by MMU ? )

2 Answers 2

1

Oups, there are different points in your question...

  1. Why is not the code for libc of other program stored in ROM?

    By definition ROM is read only, that means that it would be impossible to upgrade libc nor any program if is were stored in ROM

  2. Why are not code pages marked as read-only at MMU level?

    They are marked as read-only. Unfortunately it has no use against buffer-overflow, return-to-libc attacks

  3. What makes those attacks possible?

    The return address is not stored in code, but in the stack. All current languages (past mid 60s Fortran 4...) also store local variables in stack to allow multithreading and recursion. That means that is a program has no special stack protection and you overflow a local buffer, you could theorically rewrite the return address and that way execute arbitrary libc code.

It must be noticed that most current compilers now implement special stack protections to mitigate those threats.

1
  • Thanks for the answer. So basically code is marked as read-only but because of the fact that process execution stack (call stack) is still writable you can mess up return address and do the attack. Did I get it correctly ?
    – sec
    Jan 17, 2017 at 12:21
0

Text section of executables (where your code resides) has to be marked executable. You're not able to execute any of the instructions in your code otherwise.

Code reuse (ROP) mitigations do exist, and you can find more information about the grsec implementation at: https://grsecurity.net/rap_faq.php

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .