Strings can get you hacked! (buffer overflows, strcpy, and gets)
Vložit
- čas přidán 1. 07. 2019
- Patreon ➤ / jacobsorber
Courses ➤ jacobsorber.thinkific.com
Website ➤ www.jacobsorber.com
---
Strings are basic, but they also cause so many security problems, like buffer overruns, that new programmers usually don't understand or recognize. This video shows how careless string operations can make your code vulnerable to attack and gives some tips about what you can do to make your software more secure.
Objdump video: • How to Inspect Compile...
***
Welcome! I post videos that help you learn to program and become a more confident software developer. I cover beginner-to-advanced systems topics ranging from network programming, threads, processes, operating systems, embedded systems and others. My goal is to help you get under-the-hood and better understand how computers work and how you can use them to become stronger students and more capable professional developers.
About me: I'm a computer scientist, electrical engineer, researcher, and teacher. I specialize in embedded systems, mobile computing, sensor networks, and the Internet of Things. I teach systems and networking courses at Clemson University, where I also lead the PERSIST research lab.
More about me and what I do:
www.jacobsorber.com
people.cs.clemson.edu/~jsorber/
persist.cs.clemson.edu/
To Support the Channel:
+ like, subscribe, spread the word
+ contribute via Patreon --- [ / jacobsorber ]
+ rep the channel with nerdy merch --- [teespring.com/stores/jacob-so...]
Source code is also available to Patreon supporters. --- [jsorber-youtube-source.heroku...]
Want me to review your code?
Email the code to js.reviews.code@gmail.com. Code should be simple and in one of the following languages: C, C++, python, java, ruby. You must be the author of the code and have rights to post it. Please include the following statement in your email: "I attest that this is my code, and I hereby give Jacob Sorber the right to use, review, post, comment on, and modify this code on his videos."
You can also find more info about code reviews here.
• I want to review your ...
As a production operator I found an overflow flaw I used to "hack" the system. There was a machine that I had to load with a batch of product and then enter my name and password. One day I inadvertently held the last key of my password long enough for key repeat to start. I hit enter and the application crashed instantly. I immediately realized I had found an overflow bug. I realized I could use this to covertly stop the production line any time I wanted! If I wanted a short break, all I had to do is load the machine and fill the password buffer with about 50 characters or so and the machine would crash. Then I would call a technician to "fix" it. Usually took about 15min to get it back up and running. Shame on me but also shame on the sloppy programmer!
This is the most valuable channel on CZcams!
Hi Professor, I appreciate your effort of spreading knowledge. Please keep up the good work.
In college we were taught to prevent buffer overflows to avoid memory related issues. Didn't know buffer overflows can be used to hack as well!
Buffer overflows are most always exploited for hacking so for 70-80% of the time
It's very common with these comments on beginner vids pointing out security issues. For me, learning from doing stuff wrong is _the_ way to learn. I learn a concept much better by processing a mistake than by getting it right the first time
I know this is an old comment but it is generally better to go over the right way and to explain why alternatives are wrong. It is a shame however that security in C wasn't dealt with earlier.
You have a lot of good stuff on your channel, sir. Thank you kindly for this content.
Great video , very informative ! More on these please sir! Like based on security issues
Hi Jacob, all of your videos are great. short and precise explanation. Can you make a video explaining poll and epoll.
Hi Jacob Sorber, Thanks for the very informative videos. it's really nice.
thanks for the advice, really helpfull.
Your videos are so god damn good.
3:11 "So let's compile our stupid little test program." >D
I tried to run this example on clang and it wouldn't even let me do a buffer overrun. :) Then I found out that there's lots of research done on "buffer overflow protection" and maybe some compilers have adopted some of those techniques.
Thanks for the very informative video.
I came across this channel for interview prep.
I loved the content.
Thanks, Mayur. Glad I could help. Hope the interviewing went well.
did u get the job
@@GamerLifeYT yes, I did
He's really underrated for his explanation
The best video for buffer overflow I've ever watched!
Hi Jacob as always its a great video , can you make a video on what are the advantages and disadvantages of function pointers? In terms of time and space and security threats.
Yeah. I'll add that to the list.
Thank you man
More of these kinds of videos would be spot on Jacob! Thanks :)
Glad you liked it. What specifically did you like about this one? The security focus? The warnings about stuff that can mess things up? Or the sweet music?
@@JacobSorber Apologies, I totally thought that I'd already replied to this! Primarily the security focus. I find that looking at the code through a different lense always helps you to see things that you might otherwise miss. And a bit of sweet music is always a nice bonus ;)
@@Silverdragon98 Ok. I'll see what I can do.
@@JacobSorber Thanks for the videos!!
Mr. Jacob!!!
I'm a programmer geek. Helps out a lot
One of the reasons for the sad state of IT security is that teachers don't want their students to "initially worry too much". Which tends to then have people not learn about security at all. Like, how many people who watched the previous videos did watch this one too? And how many, having learned about strings, didn't want to bother and didn't bother.
Look at the very recent (today is 2023-03-12) TPM 2.0 buffer overflows. BUFFER OVERFLOWS! IN THE *"TRUSTED"* PLATFORM MODULE!
You have to teach security from the very first lesson. Or forget it.
EDIT: I forgot to quote Alastor Moody: *CONSTANT VIGILANCE!*
thank you, this validates my gut instinct that any ware with "trusted", "secure" or "private" in its name is anything but
also validates my refusal to """"upgrade"""" to windows 11
very clear
These videos are amazing!
Thank you!
What a video! Professor can you explain how to use the terminal in Visual Studio Code? Like you used in this video specifically?
In the "View" menu, there's a "Terminal" option. That should do it.
Great explanation
Thanks. Glad you liked it.
Thanks 😊
Great video! What are the problems with scanf and sprintf? Would love more videos on security.
Similar issue. They don't check the length of the buffer they're writing into. So, you can get overflows.
And incorrect use of printf causes a vulnerability called memory leak . This could leak the data in the stack
Most variation of printf can lead to arbitary code execution, if the user controls the format string. See cs155.stanford.edu/papers/formatstring-1.2.pdf
Hello, What happens when the memory address of the pass word is behind the memory address of the buffer? What i mean is in this example we had our password in an address after that of the buffer so we overwrite it and make it work what if the addresses were the opposite?
@Jacob Sorber Yes, Thanks a lot!
FIRST! Thanks for the informative lesson, Teacher.
Well done! Glad you enjoyed it.
But how do you do to know EXACTLY which string to input to make your hack ?
It’s as hard as trying to find the correct password with a bruteforce.
With standard libraries I always only use fgets and so on. But is there anything comparable with curses?
Yeah, there are options like getnstr(), inchnstr(), innstr().
Thanks for the video :) Are there potential security issues with PDF / adobe buffer overflows? If you suspect something has happened on your PC what is the best course of action?
I think there was one back in 2008 or so, in which Adobe Acrobat Reader was in a sandbox (using the chromium sandbox) but one of the API calls had a potential buffer overflow which could allow for arbitrary code execution. So yeah, I guess it’s a big deal.
unicode_string have built in size xD but i dont know if its originally from c
This is so cool! I will definitely use this technique for the hacking contest Unbreakable. I had no idea strcpy acted like this. How about memcpy? Does it work differently?
Glad it was useful. And, yes, memcpy works differently. It takes in a length that limits how many bytes it will copy. So, unless you can modify the length somehow, you won't be able to overflow buffers with memcpy.
Hi Jacob, Can you tell how to convert strcpy references to strcpy_s?
You just add the maximum number of bytes to copy into the destination buffer.
Great🔥
I think string in general is not save in java the recommandiation is not save passwords in string but in char[]
You can use bstrlib instead of plain strings...
strncpy may or may not be slow, but it also will _not_ nul-terminate the destination buffer if it is filled up by the strncpy call. From the manpage...
"Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated"
The example you gave only worked because your were lucky enough that there was a null byte after the end of the destination buffer.
I’m a nodejs developer, I always wish that my program runs as fast as C programs because C is soooo fast. When i hear that a C programmer says strncpy is slow my mind is gonna blow 🙃
its slow compared to memcpy, if you are using strncpy you probably have the size and bound anyway so might as well just use memcpy
@@sleepntsheep1169 🙏👍
@@sleepntsheep1169 🙏👍
I usually prefer to use memcpy instead of strncpy.
strncpy be aware of zero termination character. The function does not garantee that zero char is copied if n is equal to destination buffer size.
Honestly there's a VERY simply fix for strcpy etc that libc etc can implement, it just stops when it hits 0 in the destination string also, so taking that 10 byte buffer for example, you would need to set the 1st 9 bytes to something other than 0 for anything to be copied into those 9 bytes, otherwise they just stay 0 as strcpy would stop on the 1st byte
Yeah, you could do this, but it's not a "simple" fix. You would be fundamentally changing the strcpy interface, and requiring all users to add code to prep their destination buffer before calling strcpy. Also, you seem to be assuming that your destination buffer will always be pre-initialized to all zeros, which often isn't the case (unless you always use calloc). So, if I forget my destination-prep code I could get all kinds of memory corruption problems. And, you're adding an additional per-character check that will make strcpy run more slowly. So, I'm not sure this would be an improvement.
@@JacobSorber Mine ARE alway preinitialised to 0 as I make sure they are with "" or {0}, as for the fundamental change, that's fine, the worst that would happen is tests failing because nothing was copied
@@JacobSorber btw the per character check won't slow it down on modern hardware, only old hardware where an extra instruction makes a difference to the cycle
Imagine telling your professor that you didn't do the strcpy assignment because you were afraid it will get you hacked.
Imagine going to college thinking you'll get a better education 💀
Use memcpy()
strcpy vs strncpy? Ok so strcpy is faster but you then need to do a strlen(src) plus an if statement first on the source string. Doesn't the strlen(src) check use as much or more cpu cycles that the added cycles of using strncpy over strcpy? Seems a wash speed wise. IMO, if you have a speed concern at that level, you need to recode the routine in assembly!
That's fair.
Nope, strnCopy also has its own problems can can be many many many times slower as contrary to strcopy it has to fill up the rest of the result-string with '\0' - so if you only copy some small 32 character inputs around but the buffer is say 512 bytes it has to write 480 extra bytes every single time.
So what about C++ in c++ we are allowed and the compiler put \0 by itself
strnCopy is just as dangerous.
If you want a secure input you gotta write it your self - check the length of the input, check the validity of the input, and only after that you should use it.
With strnCopy if the input is too long you NO LONGER have a string but rather just a character-buffer - it is no longer terminated.
Exactly, which is why you have to always throw null into the last element of the buffer after the copy.
Log4j take note
😂😂😂🎉🎉🎉 0:36
yeah this sort of security cargo culting is great and all as far as making sure people are aware of the dangers of the dark arts, but it really irks me when people try to inject every concern imaginable into introductory material on complex subjects like programming.
Quite often, people just starting to learn c are doing so with FUCKING OLD compilers. Through like a terminal to a school computer, and there are artificial restrictions put on the functions, tools, and even editor they can even use. Primarily for simplicity sake, but secondarily for the purpose of giving them some context to c history that motivated decisions in the standard and best practices.
If you tell a child over and over at the top of your lungs not to touch the stove, they aren't going to have any sort of context to understand why, and now you have just put a bug in their ear about it. So they touch the stove. In something that doesn't lead to bodily harm/death like simply overrunning a buffer while learning how to program, you want to actually go ahead and push their hand onto the stove as soon as possible to show them why its bad. "Show me, don't tell me".
Honestly it's more an issue that you probably shouldn't start out by teaching people unsafe functions to begin. unsafe strcpy is something you should learn about later when you get more experienced at optimizing for speed. Until then, use the safe version as the default. It creates an issue where people have to unlearn things, when they're used to just sort of using those unsafe functions right from the start. IMO it kind of invites mistakes down the road, and the kind of mistakes that may not be evident until you get someone hacking you. The easiest way to avoid bad programming habits is to never learn them in the first place.
@@taragnor 'you' don't get that option 99% of the time. Neither do they. The curriculum is what it is. The tools are what they are.
If a school actually wants to teach modern standard c? Sure, they should just do that. But most of them are not, and the point isn't even to teach the student how to write software in c. Its to teach them about systems programming with the most obvious systems programming tools.
The minutia of what is or isn't good about what version of what set of libraries is out of scope. And there is nothing to unlearn; you just turn on the appropriate warnings and stop using deprecate functions.
Just use strncpy
Then probably just use strncpy or memcpy instead.
In my experience, strcpy() is usually pretty safe because I almost always know the maximum buffer sizes. strncpy() tends to be the exception rather than the rule and even then, it is not necessarily related to the buffer size.
better to user strlcpy() as it is safer than strncpy()
you forgot only for educational purposes
Another example of why you should use c++ or rust instead of c. Simplicity is forced into the language to the point of having naive implementations (that introduce a nightmarish amount of bugs) in core libraries. Simple and simplistic are two different things.
Your thumbnail is egregious clickbait. Go to time out.