this post was submitted on 27 Jul 2024
66 points (95.8% liked)
Programming
17001 readers
362 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yeah, that's fair to note. For a number of environments today, the base address of the stack is randomized, which is aimed at making it hard to push a static offset and exploit buffer overflows targeting the stack:
https://en.wikipedia.org/wiki/Address_space_layout_randomization
https://en.wikipedia.org/wiki/Buffer_overflow_protection
Historically part of exploiting such a buffer overflow might include the malicious code to be invoked, as a way to get it into memory, and the introduction of the NX bit to x86 permitted OSes to mark regions of memory to the CPU's MMU as only being able to contain data, not executable code. This meant that it became significantly harder to have a buffer overflow that both seized control of the instruction pointer and contained hostile code.
Thanks for your reply. This extends "smashing the stack for fun and profit" in an important way.
Interesting point.
This makes it seem like the whole concern about memory safety has become almost redundant, the chances of exploitation are just so remote, it must take incomprehensible work to discover a functional exploit that would be useful to attackers in modern software