how do hackers exploit buffers that are too small?

Go check out my Medium post on the same topic: medium.com/@lowlevellearning/your-first-buffer-ove…

A few additional notes for those who are interested: - At 3:13, we use `objdump` to find the address of the `debug()` function. Note that this only works for program binaries that are compiled with no ASLR (hence, the `-no-pie` GCC flag). Enabling ASLR will randomize the base address of the executable. However, note that even when ASLR is enabled, it does not mean that the program is invulnerable. Some techniques would allow attackers to leak the base address of the executable and thus, they would still be able to find the address of the `debug()` function by using relative offsets. - At 4:14, we determine our initial guess for the payload size by looking into the source code for the length of the `password` buffer, which is 64 bytes. This does not mean that compiled programs with no source code available to us are not vulnerable to this attack, assuming that they also use `gets()`. First off, we can reverse engineer and statically analyze the compiled code to find that `64` constant. A much easier method would be to dynamically run the program using `gdb` and inspect its memory during runtime to figure out the length of the payload needed to overwrite the return address. Alternatively, there is also a great library called `pwntools` that can also allow us to figure out the payload length by inputting a de Bruijn sequence. - This attack can only be performed if there are no stack canaries (hence, the `-fno-stack-protector` GCC flag). However, even with stack canaries enabled, this (again!) does not mean that programs are invulnerable. Some techniques would allow attackers to leak the value of the stack canary, which would render it useless since now, attackers can simply include the stack canary in their payload. - What if there are no functions like `debug()` in the first place? After all, a real production-grade application would surely have no such tantalizing target functions that allow attackers to drop a shell and execute arbitrary code? Well, even without the `debug()` function being present, as long as attackers are still able to overwrite the stack, they can still perform a technique called return-oriented programming or a return-to-libc attack. The basic idea would be to "return" to and jump around between snippets of code in other functions of the binary or even in library functions (such as in `libc`). These code snippets are called "gadgets". With a sufficiently large library such as `libc` (which is definitely used by many applications worldwide), return-oriented programming is Turing-complete. Hence, attackers can eventually do whatever they want, including dropping a shell and executing arbitrary code. The lesson to learn here is that mitigations can be bypassed and they should not be considered silver bullets in production-grade applications. Buffer overflow is also generally considered the simplest class of vulnerabilities (there are more involved ones such as double-free attacks, race condition attacks, and side-channel attacks). Try to avoid having buffer overflow vulnerabilities in the first place at all costs by reviewing your code and by using tools that could analyze your code and detect such vulnerabilities (either statically or dynamically). That is the only way to make your code truly more secure!

the biggest vuln in your server is that your service says the words "welcome to" in its announcement banner, and nothing about unauthorized access being prohibited, thus ensuring that anyone who breaks in cannot be prosecuted under the precedented legal defense "It literally welcomed me in, therefore my access was not prohibited"

In the end it's not necessarily about being a genius, it is about understanding how it works..

keep uploading more exploit dev / binary exp videos bro, great job

Wow :) very good desc of how a buffer exploit works. I knew the theory but great to see how it actually works in practice.

I like how you release this video after I had a project in my computer security class on performing buffer overflow attacks

Thanks for practical demonstration! Thank you!

Not into C at all but very educational and well explained. Thank you

Glad that your channel got a sponsor! Thanks for the content

echo "Perfect video; Amazing Content; No Waste Time; Sponsor at the end, that i see entirely for respect and becouse doesn't ruin nothing; = Great Job; More More More!!!"

this is a GOLDEN content. Please keep it up. I love your channel it's unique.

Where have you been all my life? I needed this content ❤

Absolutely love this channel :) keep up the good work!

This is my favourite channel about programming. Thanks a lot mate!

Plese make more videos like this! As someone who didn't understand this kinda stuff well I was able to (kind of) understand how a buffer overflow works! I plan to to take cybersecurity as like a hobby in the future so your videos are really nice

I think this is a perfect start

Great demonstration! In fact, there is yet another vuln in this code introduced purely by using the system() function at all. You can read why system() is discouraged in programs that run as any privileged user on the manpage for that Linux C function under the Notes section.

Exploit dev is so cool! Keep doing these!

OK, this was, obviously, way oversimplified, with much more info available to us than would be to a typical attacker, but still it illustrates the principle of buffer overrun exploit, the most common of them all, very nicely.