Programming

17513 readers

243 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

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

snowe

Ategon

[email protected]

Is there an example program that illustrates how a buffer overflow attack actually executes arbitrary code? (lemmy.dbzer0.com)

submitted 4 months ago* (last edited 4 months ago) by [email protected] to c/programming

27 comments fedilink hide all child comments

I've found lots of examples in C of programs illustrating buffer Overflows, including those of pointer rewrites which has been of great help in understanding how a buffer overflow works and memory safety etc. but I've yet to be able to find an example illustrating how such a buffer overflow can rewrite a pointer in such a way that it actually results in code execution?

Is this just not a thing, or is my google-fu rust y? Tried ChatGPT and my local Mistral and they both seem unable to spit out precisely what I'm asking, so maybe I'm wording this question wrong.

If anyone in here knows, could point me in the right direction? Thanks y'all btw love this community 🧡

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 10 points 4 months ago (2 children)

Today there are a lot of mitigations where the steps of the paper don’t work anymore,

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.

[–] [email protected] 4 points 4 months ago

Thanks for your reply. This extends "smashing the stack for fun and profit" in an important way.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago)

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