book_secure_c.md: "RELRO update" restructure/rewrite

Author: Eliot-Roxbergh

c_programming/book_secure_c.md

@@ -381,9 +381,15 @@ we may make the GOT read-only and thus avoid potential exploits. This is called
 - .got includes variable addresses, .got.plt includes function addresses: <https://stackoverflow.com/questions/11676472/what-is-the-difference-between-got-and-got-plt-section>, <https://stevens.netmeister.org/631/elf.html>
 - Partial RELRO (as opposed to Full RELRO) is default in GCC and ONLY protects .got, thus .got.plt is still writable and exploitable: <https://book.hacktricks.xyz/binary-exploitation/common-binary-protections-and-bypasses/relro#partial-relro>, <https://www.mdpi.com/2076-3417/12/13/6702>.
 - With Full RELRO we can try to perform a buffer overflow attack to replace the return address to a viable gadget already in got.plt.
-- With Partial RELRO _(here assumes no ASLR)_ can try to perform a different kinds of _simpler_ attacks to replace the .got.plt entry itself: <https://medium.com/@0xwan/binary-exploitation-heap-overflow-to-overwrite-got-d3c7d97716f1>. _My understanding is that - the stack grows downwards with new allocations and as it does the start of stack decrease, the addressing start there and goes _upwards_ meaning we cannot read/write the heap or GOT for instance (which would only be technically reachable with many new allocations that would error out due to overflow into heap memory)  (<https://security.stackexchange.com/questions/135786/if-the-stack-grows-downwards-how-can-a-buffer-overflow-overwrite-content-above/135798#135798>)._ It's possible on a non-ASLR system to directly read or write got.plt addresses (and other addresses such as data - this is necessary for normal program functioning - but stack is not reachable directly? Stack is other virtual memory somehow and only interacted with in relation to stack pointer???) no overflow necessary: <https://ir0nstone.gitbook.io/notes/binexp/stack/got-overwrite/exploiting-a-got-overwrite>, it exists in its memory space so to speak. Example with stack buffer overflow (TODO how and TODO why is overflow used here) <https://www.exploit-db.com/papers/13203>. \
-Even if technically a overflow doesn't change anything here, NOTE! Overflow attacks might however be used in-the-wild as an attacker will try to change the process' execution path without modifying the binary (as the binary could have no write permissions, or communicated with remotely over the Internet, etc.),
-which in this context could be an integer overflow leading to out-of-bounds write, overwriting a single address in got.plt.
+- With Partial RELRO _(here assumes no ASLR)_ we can perform different kinds of _simpler_ attacks to replace the .got.plt entry itself;
+<https://medium.com/@0xwan/binary-exploitation-heap-overflow-to-overwrite-got-d3c7d97716f1>. _My understanding is that: the stack grows downwards with new allocations and as it does the start of the stack decreases, moreover the addressing starts there and goes _upwards_ meaning we cannot directly "go down in memory", i.e. read/write to the heap, or GOT, for instance (which would only be technically reachable with many new allocations that would error out due to overflow into, "overlap with", heap memory) (<https://security.stackexchange.com/questions/135786/if-the-stack-grows-downwards-how-can-a-buffer-overflow-overwrite-content-above/135798#135798>) - even if we could probably use this overflow in multiple steps, e.g. \w gadgets, to achieve the same in practice._
+First of all we can on a non-ASLR system directly read or write to the got.plt addresses (and other addresses such as data) - this is necessary for normal program functioning: in this case it needs to be because GOT uses lazy-binding as described below?
+_(TODO: offtopic, can the stack be reachable directly from program via $RSP (x86_64) address? i.e. could a general arbitrary write also change the return ret address)_
+That is, no magic necessary - we can simply make a memory write - if we control the code: <https://ir0nstone.gitbook.io/notes/binexp/stack/got-overwrite/exploiting-a-got-overwrite>, it exists in its memory space (literally).
+_Example with stack buffer overflow (TODO how and TODO why is overflow used here) <https://www.exploit-db.com/papers/13203>._ \
+Why use complex overflow techniques to overwrite got.plt entries then? Answer: overflow or similar attacks might be used in-the-wild as an attacker will want try to change the process' execution path without modifying the binary (as the binary could have no write permissions, or communicated with remotely over the Internet, etc.),
+which in this case could be done by somehow overwriting a single address in got.plt via arbitrary write.
+One can imagine different ways where stack overflows or other methods could create arbitrary ("out-of-bounds") writes here
 - Note that ASLR / PIE can make these attacks more difficult. GOT-related attacks are done to bypass certain protection mechanisms such as NX-bit.