Hello and welcome to the cyber ery secure coding course. My name is Sonny wear, and this is buffer overflows
Now. First, we'll start with the definition.
A buffer overflow is an overfilling of particular variables. Usually buffers or resource is resulting in issues with the memory management. Such issues can include modification of memory manipulation or access of memory addresses
or even segmentation. Fault, otherwise known as program crashed.
Now taking a look at the Sands top 25 items that are related to buffer overflows. We can see in this chart that we have five,
so the rankings are rank 3 18 2023 24 then we have the description of each. Now we're going to look in detail at each of these and look at some sample code as well.
First, before we start getting into
understanding, buffer overflows. Better
commonly, I will hear programmers that are taking secure coding classes state that
they don't have the need to to learn or understand, but for our flows, because it doesn't apply to their language. I just put this slide together to help programmers to understand how foundational the language see is
for many of the programming languages
that are commonly used in the industry.
Included in that is object See PERL PHP go ock python ruby, just to name a few. These are things that, as programmers, we probably code in
all the time or a least on occasion.
be aware that buffer overflows are quite prevalent, even still,
and they can even occur in COBOL programs. So let's start with the concept of a buffer overflow.
It's exactly what it sounds like. So this is where we are going to see the stuffing or putting of more input into a container than it can hold.
Just a CZ you would do with a pitcher of water as you poured into a cup. It's going to spill an overflow that cup,
and so the concept behind buffer overflows is very similar. The only difference is that instead of having a segmentation fault, which is three usual way that a program will handle a buffer, overflow or if the resource is are exhausted
instead of that, Attackers will basically control that crash so that they can then manipulate memory
and insert shell code.
So we're gonna take a look at some simple examples of how a buffer overflow might look on the stack. But before we can do that,
we need to just understand a few concepts.
So the stack is basically a last in first out. So that means if you think of a stack is exactly as it sounds, something that you layer one thing on top of another.
Then the last thing that you put in is gonna be the first thing that you're going to take off.
And E S P is a registry that's available inside of a CPU inside of a processor. And the E S P is actually your stack pointer. And what this is going to do is it's gonna point to that last thing that was placed on top of that stack.
Now this is generally referred to as a push. So you push things onto the stack and then you pop things off of the stack.
The other register that I want to talk about is the CBP. This is the base pointer.
Basically, base pointers are what point to your local variables inside of your program or, more specifically, local variables inside of your function. Whenever you have a function that comes onto the stack.
There are stacked based pointers that point to your function
when it goes to get set up, and then when it goes to get tourney down
and so you'll see, Just as you see with the push and pop, you'll see this set up and tear down with base pointers as well.
The only other one that I wanted to mention is the instruction pointer instruction pointer is actually what it sounds like. It's pointing to
the next line of execution in your program. So bear these in mind as we look at the next picture. So the stack in a regular execution of a program
is going to have an area where the arguments get pushed onto the stack and then those arguments then get placed into your function. You can see in this diagram we've
got memory addresses that are represented at the top in the bottom,
and then we have the top of our stack,
And then we have the top of our frame or stack frame pointer, which is e B P. S O. This is ah, light representation to just give you an idea off how your program may look in memory
now when we have an overfilled buffer. What happens is
there's no bound checking that is done. And so an attacker is able to actually spill over a particular buffer or race eyes and control the program so that it doesn't crash.
But it actually instead will execute some
some arbitrary code that they have inserted instead of the buffer holding the string. Hello. It will instead be holding some evil shell code that's been inserted by the attacker.
And then what happens is
the instruction pointer will eventually fall to the beginning position of where this evil shell code is located.
This also has to do with a return address from the function.
Now please realize that there are different types of buffer overflows. There's heap overflows, et cetera,
but this is the general idea behind the concept.
So now let's go ahead and take a look at some sample code. All of the samples that I'm showing you are from C or C plus plus.
The 1st 1 is our Sands Top 25 ranked number three C W E. 1 20
buffer copy without checking the size of the input. This is our classic buffer overflow, just like what we saw on our previous slides, where we had that string copy.
So we now understand if we declare an array of size eight
and we decide to pass in an argument that contains something larger than eight. So let's say that R V sub one
contains a size of 10.
We're going to overflow that buffer in actually corrupt memory.
This is mainly due to the fact that the string copy doesn't do any kind of bounds checking.
And so that's where the potential for the buffer overflow can occur.
And, of course, the subsequent insert of arbitrary code by an attacker.
The next ranking is number 18. This is C W E 6 76 Dangerous Functions String Copy. Example. One.
In this example, we are assuming that the string value in slash A is actually mill terminated and also assuming that there's sufficient memory that has been allocated on the stack to accommodate the contents of
the source buffer into the destination buffer.
that all plays into the slides that we saw earlier.
Now, the second example for dangerous function is F scan F,
and this is where we're seeing that there's no bounds check that's being performed to properly limit the amount of data that the function can right? So this starts getting into actually crashing
onto the system itself, which could possibly lead to a root window being open.
The next ranking is number 20. This is C W E. 1 31 incorrect calculation of the buffer size.
Also known is off by one you'll see it referred to is off by one.
In this example, we see that the shift operator is being used. It's actually quite benign. It's being used to drop off a sign. The problem is that there is that potential of being out of bounds for our race eyes or a buffer size
because one skin, there's no bounds tricking being done.
The next ranking is number 23 C W E. 1 34 buffer overflow format string.
This is where if the attacker can control the argument that gets passed in, then it could actually reveal contents of the stack, specifically memory locations. And we actually saw this in a previous module
in a similar type of attack where we could see the
the actual contents of what was being stored locally in in a variable,
and then the final one is ranked number 24. This is C W E 1 90 insecure overflow or wrap around
if we get a response. And in this example, the variable is in rest.
If in risk has a value that is larger than four bites. And typically
the size of char pointer is about four bites.
Then the argument to ex Matlock is going to be zero, which could cause Infinite Loop, which obviously could exhaust her resource is
producing a buffer overflow situation.
Now our case study is on Android. They had a stack buffer overflow vulnerability with their key store that's actually stored on the phone itself. It goes back to the code.
If you look at the sample code I've pasted there, you could see that there was no bounds checking done on the key name
into the file name in a particular method, and so that made it vulnerable to buffer overflow.
Now let's move on to the demo portion of our module