book_secure_c.md: RELRO minor minor

Author: Eliot-Roxbergh

c_programming/book_secure_c.md

@@ -372,7 +372,7 @@ Unrelated?; "There is one GOT per compilation unit or object module, and it is l
 ( So with ASLR e.g.; stack starts at random address (randomness but stack/exec/heap/libs are still in a certain area, and grows in a certain direction), heap starts at random address, lib (ld.so?) starts at random adr (must have PIE..?), exec starts on random address (if PIE) )
 
 
-##### Lazy Binding, PLT, GOT (RELRO)
+##### Lazy Binding / RELRO, PLT, GOT
 
 **tl;dr** By disabling lazy binding (i.e. to instead load all dynamically linked functions at beginning of execution),
 we may make the GOT read-only and thus avoid potential exploits. This is called **RELRO**, and can be passed to the linker.
@@ -381,7 +381,7 @@ 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 changes, the addressing start there and goes _upwards_ meaning it cannot reach the heap or GOT for instance (which would only be reachable with a new allocation 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?) 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>. \
+- 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.
 - Note that ASLR / PIE can make these attacks more difficult. GOT-related attacks are done to bypass certain protection mechanisms such as NX-bit.