Part 2 Explanations

Video Activity

This lesson opens with the definition of a buffer overflow. A buffer overflow is an overfilling of particular variables (i.e buffers) or resources resulting in issues with memory management such as modification of memory. Participants also learn about the top 25 buffer overflows and the sample code pertaining to these buffer overflows. When an atta...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
9 hours 31 minutes
Difficulty
Intermediate
Video Description

This lesson opens with the definition of a buffer overflow. A buffer overflow is an overfilling of particular variables (i.e buffers) or resources resulting in issues with memory management such as modification of memory. Participants also learn about the top 25 buffer overflows and the sample code pertaining to these buffer overflows. When an attacker is able to control a buffer overflow, they can control a crash and insert shell code, making an unsuspecting users information vulnerable. Participants also receive samples of codes in C/C++; examples include buffer copy without checking the size of input as well as dangerous function. Finally, the instructor presents a case study about Android KeyStore stack buffer overflow.

Video Transcription
00:04
Hello and welcome to the cyber ery secure coding course. My name is Sonny wear, and this is buffer overflows
00:12
Now. First, we'll start with the definition.
00:14
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
00:33
or even segmentation. Fault, otherwise known as program crashed.
00:38
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,
00:48
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.
01:04
First, before we start getting into
01:07
understanding, buffer overflows. Better
01:11
commonly, I will hear programmers that are taking secure coding classes state that
01:19
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
01:37
for many of the programming languages
01:40
that are commonly used in the industry.
01:42
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
01:56
all the time or a least on occasion.
01:59
So
02:00
be aware that buffer overflows are quite prevalent, even still,
02:05
and they can even occur in COBOL programs. So let's start with the concept of a buffer overflow.
02:14
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.
02:27
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,
02:37
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
02:57
instead of that, Attackers will basically control that crash so that they can then manipulate memory
03:05
and insert shell code.
03:07
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,
03:15
we need to just understand a few concepts.
03:20
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.
03:34
Then the last thing that you put in is gonna be the first thing that you're going to take off.
03:39
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.
03:59
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.
04:09
The other register that I want to talk about is the CBP. This is the base pointer.
04:15
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.
04:30
There are stacked based pointers that point to your function
04:34
when it goes to get set up, and then when it goes to get tourney down
04:40
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.
04:47
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
04:57
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
05:08
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
05:25
got memory addresses that are represented at the top in the bottom,
05:30
and then we have the top of our stack,
05:32
which is R. E S P.
05:35
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
05:49
now when we have an overfilled buffer. What happens is
05:55
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.
06:12
But it actually instead will execute some
06:16
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.
06:30
And then what happens is
06:32
the instruction pointer will eventually fall to the beginning position of where this evil shell code is located.
06:43
This also has to do with a return address from the function.
06:48
Now please realize that there are different types of buffer overflows. There's heap overflows, et cetera,
06:56
but this is the general idea behind the concept.
07:00
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.
07:09
The 1st 1 is our Sands Top 25 ranked number three C W E. 1 20
07:15
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.
07:27
So we now understand if we declare an array of size eight
07:31
and we decide to pass in an argument that contains something larger than eight. So let's say that R V sub one
07:42
contains a size of 10.
07:45
We're going to overflow that buffer in actually corrupt memory.
07:48
This is mainly due to the fact that the string copy doesn't do any kind of bounds checking.
07:57
And so that's where the potential for the buffer overflow can occur.
08:01
And, of course, the subsequent insert of arbitrary code by an attacker.
08:07
The next ranking is number 18. This is C W E 6 76 Dangerous Functions String Copy. Example. One.
08:16
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
08:35
the source buffer into the destination buffer.
08:39
And, of course,
08:41
that all plays into the slides that we saw earlier.
08:46
Now, the second example for dangerous function is F scan F,
08:50
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
09:07
onto the system itself, which could possibly lead to a root window being open.
09:13
The next ranking is number 20. This is C W E. 1 31 incorrect calculation of the buffer size.
09:22
Also known is off by one you'll see it referred to is off by one.
09:26
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
09:46
because one skin, there's no bounds tricking being done.
09:50
The next ranking is number 23 C W E. 1 34 buffer overflow format string.
09:58
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
10:16
in a similar type of attack where we could see the
10:20
the actual contents of what was being stored locally in in a variable,
10:26
and then the final one is ranked number 24. This is C W E 1 90 insecure overflow or wrap around
10:35
if we get a response. And in this example, the variable is in rest.
10:41
If in risk has a value that is larger than four bites. And typically
10:46
the size of char pointer is about four bites.
10:52
Then the argument to ex Matlock is going to be zero, which could cause Infinite Loop, which obviously could exhaust her resource is
11:01
producing a buffer overflow situation.
11:05
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.
11:20
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
11:28
into the file name in a particular method, and so that made it vulnerable to buffer overflow.
11:35
Now let's move on to the demo portion of our module
Up Next