this post was submitted on 27 Jul 2024
68 points (95.9% liked)

Programming

17248 readers
257 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
 

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] 2 points 2 months ago* (last edited 2 months ago) (7 children)

@LainTrain There used to be approximately a million examples floating around in the web. You could just write a simple program with a fixed-size stack buffer at a repeatable address, overflow a return address with a crafted string, return to the overwritten stack buffer full of shellcode. All of the mitigations (stack canaries, W^X, ASLR, CFI, canonical addresses, ...) mean that you have to either use much more elaborate techniques (ROP/return to libc, address leaks, ...) or you have to disable the mitigations to see a working exploit example, which is pretty unimpressive.

[–] [email protected] 3 points 2 months ago (6 children)

Thanks! The reason I was looking for an example is because I understand:

overflow a return address with a crafted string, return to the overwritten stack buffer full of shellcode

In principle, but not in practice. Especially the last part.

I have my char buf[16] and some char * ptr = buf; and then a gets() gets a 20 char string, causing a buffer overflow either then or when the buffer is read where it reads out of bounds.

I've done this many times, sometimes intentionally, and if I visualize the memory as one continuous line where the ptr is stored at the precise address buf[20] is at, allowing me to write into that memory location a new address for the pointer by having part of the string given to gets() be a new memory address at the address of ptr, so that next time that pointer is accessed in a program, it leads to an arbitrary memory read, and the arbitrary pointer address can be to still further down in the initial string we gave to gets(), e.g. buf[40] where our shellcode is stored, but how to do this - implement it in practice (so - in code), I don't really know.

Specifically I don't know how to make a pointer at a predictable constant address so it's stored address can be overwritten, and how to make the reading of the resulting maliciously modified pointer also somehow execute code. I'm guessing it can't just be a char pointer reading in data, right?

[–] [email protected] 3 points 2 months ago* (last edited 2 months ago) (1 children)

Specifically I don’t know how to make a pointer at a predictable constant address so it’s stored address can be overwritten,

This is one of the things that I mentioned in my above comment on mitigating buffer overflow attacks, that address randomization is one of the mitigations. Are you trying to create an exploit that will function in such an environment?

If so, I'd still start out understanding how the attack works in a non-mitigated environment -- it's simpler -- and then learn about the mitigations and efforts to counter them.

[–] [email protected] 1 points 2 months ago

I agree, I think for now I'd like to try to create a demo exploit and exploitable program like this without considering ASLR et al. and then at some point in the future perhaps look at a return to libc type deal to understand that as well.

load more comments (4 replies)
load more comments (4 replies)