Most important message to be conveyed here, *never* trust user input. Always check it, always restrict what you do with it.

Be really fun to see your 'secure' server broken live and record the actual memory. Great video!

In this reality some hackers love strings more than physicists.

And all this just because someone decided that extra few bytes for storing the length is too expensive. Which is kinda strange, because in fact pre-determined length can increase performance dramatically. There is a known recent story about GTA modder who cut the game loading time by 70% just by eliminating strlen() calls.

Technically you must read at most 63 bytes/characters. The 64th byte in the array is the null byte. And you need to remember to set it to null when creating the array.

You can always implement strings as structs and store the length data. It's C, you can do anything. Unfortunately, you still need to get the data back out pretty frequently as the usual null terminated char arrays in order to use other functions.

I think you should make a course on how to program in C securely/safely for beginners.

Honestly there are no excuses for buffer overflows in your programs today. With all the tools available to devs you have no reason for this to still happen.

I have to say this channel is very, very, very good. You really are delivering quality wise.

We should all be grateful that code is getting safter

That's why the newer secure versions of these input functions also include a max data value so they can ignore any input over the intended amount making them much more difficult to exploit with buffer over flows.

In Pascal-style strings, the length is encoded as a byte at string[0], or sometimes the first 2 bytes (first 2 indices). This is a practice that the Macintosh pre-Intel era used in its API, and how strings are usually stored in binary file formats.

4:59 "Randomize Memory Data Structure" Perl 5 does this with hashes starting in 5.8.1 and the Perl porters improved the feature in version 5.18. It's in the perlsec manual under the section "Algorithmic Complexity Attacks".

Having just completed my CompTIA Network+, Security+ & PenTest+, this is a perfect example of the need for sanitisation of user input!!! Great video and you’ve just got a new subscriber!!

It was informative! Thank you!

Remember to pass the -fno-stack-protector flag when compiling your C programs for added stack based security.

Read the gets(3) man page if you feel like having some fun. It's not long. Opens with "Never use this function" and ends with "ISO C11 removes the specification of gets() from the C language." It also mentions that "there can be no guarantees that the function will even return" - which is due to the return address manipulation exploit in this video. 5:14 I wouldn't recommend using strncpy(3). It does not guarantee that the result will be null-terminated, so it's just another thing to keep in mind when copying. Use snprintf(3) instead, even if strncpy(3) is technically safe.

more buffer overflow please because I've always watched videos about them but never have "clicked" as simple as this one

As a C programmer I would never uses gets() in a professional program. I always bound check when copying to buffers.

This is why when printing something, I was told it's always best to use fprintf() or sprintf() instead of basic printf().

If someone reads this know that strncpy is broken and should not be used. If input is larger than buffer, no nul is added to the buffer. Never use strncpy without the line after: buffer[sizeof(buffer) - 1] = ‘\0’; If you don’t like to write this every time, use strlcpy.

I am so glad your videos are short. Theyre so good.

The problem comes down to - in a large part - null terminated strings. I thought it was a lousy string implementation back in the dark ages. Nothing since has changed my mind.

That's why you're supposed to use fgets, which gets both string and it's size. fgets(string, sizeof(string), stdin); In case of scanf, you can define the number of characters... char array[64]; scanf("%63s", &array); But I guess there is a way to overflow those too... Not that I know about it.

To don't have buffer overflow there is a simple way: ditch low level langs, for langs like: for ex. kotlin, or rust

Only thing more fun than a buffer overflow is a string format exploit Stack canaries, ASLR, not executable stack made buffer overflows rare now.

great video ! how did you get the function description in c 2:30 ? as a beginner that would really help me understanding the functions in depth

I love how c is inexplicably the scapegoat for every single buffer overflow ever

This is great! I wish I had this years ago when I was learning more about Buffer Overflows for a pentesting cert. It took me like a year to actually perform my first BO but it was still messed up but it worked lol.

The real issue is that a huge amount of projects rely on c libraries. It would take decades the change all the programs. Than you have to check all the c++ libraries as well. After that all the libraries from another unsafe programming languages.

I find it funny that c is the scapegoat for string overflow

crystal clear explanation.. could you please make a video about basics of assembly also??

Very interesting, please do a video about the mitigations!

Thanks again👍!

I come from the world of VAX/VMS. They handled strings/pointers VERY DIFFERENTLY, likely because one of their priorities during development of the heavily intertwined hardware and software, SECURITY WAS A PRIOTIY ! This was the early 80s, so VAX was a 32 bit computer. A "descriptor" (fancy C pointer) was FOUR entities. An 8 bit "class", an 8 bit "data type" and a 16 bit "length". A CLASS could be a fixed or variable length entity. Fixed length was most common. The data type (DTYPE) could be many things making it a descriptor to a byte, word, long word, quad word, etc. So CLASSS=1 and DTYPE=24 was a fixed lenght string. Buffers were ALWAYS defined to have a fixed length and any system library/service routine respected that length ! There were other hardware devices that prevented access to different parts of memory that did not belong to your process.

Unfortunatelly, strncpy(3) (and strncat(3)) is vulnerable too. It adds no NUL if source string size is equal to "n" argument. You should use strlcpy(3) instead, if impemented (or invoke strncpy(buffer, src, sizeof(buffer)-1); and make sure that buffer[sizeof(buffer)-1] = '\0';). Also, strncpy(3) fills the rest of buffer with NULs, which creates performance issue.

Nice and clear presentation

Awesome video ! Thanks a lot for explaning about buffer overflows with an example.

The dumb idea of zero termination pascal has a bit more safety. Also in C you typically use the n functions to minimize potential damage. Store strings in strechy buffs and never use functions that don’t allow you to take the max len with them. I doubt this add will push anything to the stack i suspect it will directly use registers as there are still plenty of them open and passing via stack is in comparison really expensive. The macOS arm64 calling convention is a but of a weird one when we then go to structures..

Interesting fact, nowadays as memory is relatively cheap, programmers reserve more bytes for a string as would be needed. Instead of 64 bytes, they reservre 1024 bytes and so on. This simple trick can be helpful in mitigating the overflow attack as it's harder to overflow.

Didnt know hackers were interested in theories of quantum gravity as well ;)

In C++, we have a similar problem when we use a char pointer. One solution I found was to use cin.width(length) and cin.ignore(some large number) These two commands ensure to consider a string upto length and ignore the rest of the characters entered. Is there a problem with this approach?

I got a good laugh out of the stock video at 0:10

It’s not that prints gets were bad at the time, just sloppy programming not checking before using, now newer safer replacements were added to enforce checks tho still majority of programmers are not fully checking and I don’t think this will ever change and forever have exploits that should of never been

Well explained! Thanks

Current GCC wont even compile gets() It will explicitly tell you "Dont be a dumbass, use fgets()"

What I don't understand is how the hacker would know what value to set the return address to. They would have to have access to the code or decompile the binary or something.

So happy “Code is getting safter”

I absolutely LOVED this video! Keep up the good work 😊!

what a good and neat explanation and not a fast and nerdy voice! thank you

3:00 - this is incorrect in AArch64/64-bit ARM. Without compiler optimizations turned on, arguments would be pushed to first and second general registers. With optimizations turned on, this function would be completely ignored and compiler would just calculate it in compile time. So this issue is defined by different rules under different architectures, and I guess (since I'm not working with X86 assembly) what you have pointed out is X86_64 thing.

I'd be interested in how they know the address of the function they would want

4:45 printf is also a vulnerable fuction if you direcly pass a string without format

Great Video thank you for explanation :)

I always questioned why my teacher told me to put hard limits on the length of passwords my users can even input, let alone check. Guess this was one of the reasons.

No more null bytes from now on .. Use unsigned for a counter ...

..Good reason to use a managed language such as open source C#

Coding is definitely getting SAFTER

🤯 I never knew it was like this

Does Zig have these problems?

0:09 did someone notice the KZfaq video playing on this mans computer in the stock footage?

Now i get it ! thx

How would a hacker find the address to the debug function? @4:15

why is the function still there if even the dev said to not use it????

Just don't keep sensitive information in memory unsecured

Please: more on the buffer overflow; and some on mitigating against it and protecting against it.

Makes me wonder why gets() is even still supported in any compilers if it's _so_ deprecated that its documentation literally says "don't do this". (Okay, apparently it was removed entirely from the C11 standard, but anything based on C99 is still more or less required to include it.) And why null-terminated strings became the preferred implementation is weird when (at least for common strings less than 256 chars) adding a separate byte to specify the length up front not only avoids much of the buffer overflow scenarios, but doesn't even add any memory cost! You'll have to reserve one extra byte in memory either way (either a null byte, or a length byte), and how much space you might need to (dynamically) allocate to hold a string is a separate problem.

Using sprintf while watching this 💀 Was just trying to convert a float to string on a micro controller 😢

I don't quite get it. If we change the return address with the buffer overflow we are outside the main function, but that doesn't automatically mean that we end up in the debug function, does it? And why does the buffer owerflow changes the return address, shouldnt it simply change the value of the address which comes after the allocated memory for the string?

Never trust a user, always assume that they are trying to hack you and your other users.

4:26 yeah lets change gets function not accept more than lenght is. fixed! and if write bigger then password is wrong it would not run debug. kinda bad example. overflow would not correct password. it would return anyway correct position

Would love to hear more about the other mitigations and how to use them

If you are trying to overflow the buffer and placing the address of the 'debug' function as the return address, how do you find out the address of the debug function? Also, how do you know when to input the address of the debug function so that it exactly goes into the return address?

If the string has to be local to the return instruction on the stack, how would you ensure that where you’re storing is actually on the stack and not in a register? I’ve had this question for a while now and I feel like I’m missing some important concept.

That's one of Zig's nicer improvements: it uses fat pointers for strings so that a class of buffer overflows can be ignored (and, provided you pre-allocate buffers, most user input is safe by virtue of using the buffer size).

bro your thumbnails are absolutely hilarious

Basically the user/threat actor gaslights the vulnerable program into submission and giving up the data it has

Is it really that hard to bounds check user input?

Sucks that strings make up like 80% of all programming lol seriously, command line tools, compilers, web browsers everything relies so heavily on regexes and string comparisons it's insane

but isnt it solvable like in 3 lines of code? In a project im currently doing I just did a loop that kept reading from the buffer until it reached '\0'

These vulnerabilities r present in C++ iostream library functions or not?

This mitigation wouldnt take only a video rather than a 2 full university courses

Small and powerfull video 👏👏👏👏

i love me a good buffer overflow

Nice video, but it did not actually show how buffer overflow can be used to steal data. All that was shown was that buffer overflow while overwriting memory causes the application to crash, because a segmentation fault occurs and.... that's the end of the hacker's adventure in stealing information.

Hey, I am at a freshman year at automation of atomic and energetic process at my university. I was told to not use gets() no way, only fgets() , but they didn't told me about this part . I hope to see more videos about C from you.

4:10 Line 2 Syntax Error: Did you mean "#include"?

Lol, I literally had a lesson about the NUL an hour ago

So if the return address is corrupted thanks to buffer overflow in C, why does the program enter the debug function? I don't see the connection there. It seems to me like the program should just crash incase the return address is overwritten as it now has nowhere to return after encountering the return statement.

it's getting safter?

4:48 "Code is getting safter" Read again.. (Safter)?

Hey Rust, we need your help.

Quality

at 4:54 the vid is from hacker typerr

All programs will always behave deterministically. Given the same input, they will always give the same output. By same input I include things like memory state, environment variables, or physical randomness generators, etc. What "undefined behavior" usually boils down to is what is most easy for the compiler to implement. It could connect to your bank and transfer all your money to somewhere else. Or it could just write into the buffer until the input stops or the kernel says "SIGSEGV" You are also imprecise about the calling convention. It is different in 32 bit and 64 bit. In 64 bits a number of registers are used for arguments before the stack is used. In order they are RDI, RSI, RDX, RCX, R8, R9. After that they are stored on the stack. Also in both cases the old stack base pointer is stored on the stack as well to restore the previous stack frame after the return instruction. It is also worth noting that EAX is used for the return value. It's interesting that you can even get remote code execution due to an insecure printf call. printf is outputting text, how would you do anything other than leak information? %n is a really stupid idea that is not only useless but dangerous, allowing basically arbitrary write, including overwriting the return address with whatever you want. Also no. Most definitely not. gets may be safe to use in some examples, it is still a really bad idea to have a buffer overflow in your program. Best case you get a DoS when someone feeds you unchecked data and your program crashes. Even with NX, canaries, ASLR and RELRO you can still have a problem if you can leak addresses using other bugs. ret2libc and ROP are still a thing to this day. Don't use shitty c functions that only stick around for compatibility. c is for low level programming, there are no checks, that is all on you. And you are required to understand what the memory and the processor are actually doing if you want to write secure code. In my opinion, c belongs on embedded devices with very limited memory capacity and literally nowhere else. c++ gives nearly the same performance, but you get all the handy library functions that are actually made and updated to be safe, the convenience of namespaces, not throwing confusing structs everywhere, smart pointers, templating and all that without the language overheads of even higher level stuff, like java. And of course you get actual types for arbitrary length strings instead of throwing stuff into arrays.

is this just a security issue with c and c++ or are other languages like javascript and C# also vulnerable to it?

Would you say the C++ equivalent ( getline (std::cin,UserIn); ) have the same vulnerability?

I'm just going to assume that all users are criminals

4:16 but we should know the address of the debug function in memory right? How can we do that? (for learning purpose only)

Guys I started studying in a university ( computer science and programming ) so I have a question how can I detect if my Programm is getting buffer overflow ?