Strings can get you hacked! (buffer overflows, strcpy, and gets)

everybody how's it going I've been talking a lot about strings lately and one of the things that comes up a lot when talking about strings is security when I posted my first beginner strings video I very predictably got this comment and you're gonna hear all over the place people say don't use string copy don't use it don't use string copy it's unsafe it's going to get you hacked and I didn't mention any of this in my previous video because my focus was on simplicity I wanted you to really understand the core of how strings work in C and not really initially worry too much about getting hacked or about security and security tends to add some complicated details that I didn't want to get into but I think it's time so today we're gonna talk about programming decisions that you can make that could get you happy now there are a lot of things we could talk about about security there are a lot of ways that an attacker could compromise software that you write today I just want to talk about one of them and that one relates to strings specifically I want to talk about buffer overflows sometimes they're called buffer overruns the idea is simple in see a string doesn't have a built-in stored length in Java they do in Ruby they do in Python they do all of these languages store a length with your string that tells you how much space is available for that string but in C we don't do it that way we just know we're gonna start at a location in memory and we just march along until we hit a null character that's 0 that tells us that we've reached the end of the string and that's how functions like string copy work they just march to the end of the string and they just keep going until they hit a null character so what does that have to do with security well let's look at an example let's say that I use string copy to copy a string into an array that I declared let's say I give it 10 bytes now the problem is that string copy doesn't give me any way to guarantee that the source string the thing that's copied in is going to fit string copy doesn't know how big the array is so it's just going to copy characters until it reaches 0 and if the string that we're copying in is too big then we're going to overflow our array or our buffer and that's why it's called a buffer overflow or buffer overrun and that can cause us some problems ok so let's look at it for today I want to use a very simple demonstration we're going to write a very program it's going to take two arguments a password and a string that I want to print out now with a real application it would probably be something more sensitive but this will be good enough for demonstration purposes then let's make two arrays ten bytes each for simplicity and having passwords in plain text is another really bad idea but let's ignore that for now we can talk about secure passwords in a later video for now we are talking about buffer overflows so this will do now we're gonna copy the message into the buffer array now this is kind of arbitrary but let's say that I copy the message into the buffer array and then I check the password using another little useful string function or string compare and if it matches we print out the buffer and if not we'll print out an error now this is a really simple example and there are different ways you could do this but I think that this will do for today's purposes I'm also going to test this on Linux today this specific example may not work for you depending on the compiler or compiler version you're using but hopefully you can adapt it to your own setup once you understand the principles involved so let's compile our stupid little test program and notice that if I run it with the correct password it works as expected and if I run it with a bad password it prints out an error just like we want it to now let's put on our security hats and play bad guys for a minute and let's see if we can break this program and I mentioned that that hard-coded password is a problem just to quickly show you why we can use the strings utility and it's going to dump all of the printable strings in a dot out and I don't necessarily know which one is the password but I can try all of them there aren't that many and eventually I get it right I could also disassemble the binary and look at the assembly code and that might make things even easier to figure out but that's not the attack I'm really interested in today I'm interested in buffer overflows so let's see what happens when we break the rules what happens if I pass in a message that is too long so that seems okay for now we were able to go beyond ten I know it doesn't fit in my array because my array only has ten characters in it but seem okay so far no behavioral changes but let's make it longer so we keep making the message longer and longer eventually we're gonna see that it starts to break and it starts to give me an error even when I give it the correct password so that's a little confusing but things get worse because I can do something like this I actually stick Jakob here at the end and then I can use Jakob as the password and things check out confused let's take a look at what happened first off let's look at the program symbol table and see where our variables are located in memory now I'm using object dump to do this I did a video about object dump a while ago linked in the description if you missed it but simply this lets us see the addresses where these variables are in memory and notice that they are right next to each other the addresses are in hexadecimal so they are 16 bytes apart so when I overwrite the end of buffer at first it's okay because there's 16 bytes it has a few bytes of cushion but eventually I start overwriting the password and so I can then replace the password with whatever I want and basically change the program's behavior and get it to accept any password that I want now in this case I change the password but buffer overflows allow a wide range of attacks because it really allows me to arbitrarily change any memory that comes after the buffer so depending on where things are in memory I could change the code I could write my own code in there and then I could sometimes I can actually get the program to run that code and all of these different attacks of course would be more complicated and I don't really have time in a short video to go through all of these and how they would work maybe in the future but the point is is that functions like string copy make this kind of attack possible and of course this example is specifically crafted to make it super easy for me to simply compromise in the way that I just showed you other programs may be more challenging and just the presence of a buffer overflow doesn't necessarily mean that you can get compromised but it's a very dangerous thing to allow and it can cause all sorts of problems for you and it is specific to the compiler if I use a different compiler that happens to put things at different locations in memory or maybe it allocates my space for my variables differently well I may have to actually attack in a very different way and maybe those things will actually make the attack not work anymore because really I'm taking advantage of knowing where things are in memory to do this attack but so what do you do as a programmer if you want to avoid buffer overflows first of all you want to keep an eye out for any time that you are accepting input from a user especially if you don't fully trust that user to play by the rules so anytime that you're reading input from the user from the terminal or from standardin or from the network or from a graphical user interface whenever you're receiving data from a user you need to be careful because you don't have control over what they send you so anytime this is the case you want to make sure that you don't use functions that don't check the length of the input that's coming in and I've already talked about how string copy is this way but there's also functions like gets gets just reads a line of text from standard in and it doesn't check how long it is it just keeps going until it reaches a newline character and so again there's an opportunity for buffer overflows and one thing you'll notice is that there are warnings in the documentation for both string copy and forgets that basically warned you about this problem and you can see that here and here so let's really quickly look at some safer options string copy has a safer counterpart string or STR n copy is just string copy but it's got an N stuck in there which takes an additional number that tells you not to copy more than that many bytes and if I change my example to use STR n copy instead well then our little attack no longer works and that's nice now some programmers complain that STR n copy is slow and it is slower than string copy but the difference doesn't usually matter for most programs but if it does matter for you if you really need to squeeze every last bit of speed out of your program then you can always use string copy and just make sure you check the length of the string before you copy it and then of course if it's too big don't copy it and of course any time you know where a string comes from and you can guarantee that it will be small enough to fit inside your buffer well then you can use string copy without any concerns because you know it will fit but many people recommend just using STR n copy and or checking the length because it's easy to make mistakes it's easy to forget it's easier to think oh this is safe when in fact it's not because it depends on user input also if you're wondering about gets and safer alternatives you can always use F gets and that's yeah you can see that here it is safer it limits the input size and there are a lot of other places you can get in trouble with buffer overruns there are other functions that you can run into trouble if you're not careful like scanf and s printf but that's all the time I have for today so hopefully this is helpful hopefully it it makes you aware of this issue in your programs hopefully now that you're aware of it you can craft programs that are less vulnerable to this kind of attack and I hope that's helpful in the future code that you write so happy secure programming I'll see you in the next video [Music]

Channel: Jacob Sorber

Views: 29,179

Keywords:

Id: 7mKfWrNQcj0

Length: 9min 4sec (544 seconds)

Published: Tue Jul 02 2019