Hello and welcome to the cyber very secure coding course. My name is Sonny Wear, and this is buffer overflows, medications, countermeasures and defenses.
So first, the defense's overview. We're gonna look at three main areas,
dangerous functions, and they're safer equivalent. There's a reference table that we're gonna go through
static format strings. This is where we're going to use static format strings for the display of our values instead of arguments.
we're gonna take a look at a safe memory allocation example where we're using a wrapper function for preventing insecure, overflow or miss allocations of memory.
So first are dangerous functions in their safer equivalents. You'll see, on the left hand side the unsafe function. We've talked about several of these already, but strained copy has a safer function version, string, copy underscore S.
And this continues on down the list.
Now, please realize that the the safer functions that are listed on the right
may not actually be called these names on your particular platform. Solaris platform calls them by a little bit different name.
The ones that are shown here should be the names on Intel platform, but realized they might be slightly different. So please reference your documentation for your particular platform now for the static format strings. Of course,
this is going to address those formats string attacks that we saw.
So instead of allowing the argument in this case command buff to be printed out to the CIS log, we're going to pass the value that's in command buff
and display it as percent s. And so, by using the aesthetic format string instead, we can ensure that no memory leaks will be shown
safe memory allocation. This is an example of a function that actually performs
at in a ray check before allocating memory. And so this is an idea that you could extend, of course, to any kind of dangerous function or
allocation to ensure that you do not overspill your data type as such as an inter overflow situation or allocation of memory that is not available
now. I also wanted to give a nod to the non programmer defenses because there are quite a lot out there
from a processor or chip manufacturer perspective. There's theme no execute bit or in ex bit. It's also known a step.
What this does is it essentially prevents the stacks smashing
that we saw being done in the demo, so it prevents the execution of show code on the stack.
Now there are ways around it, and there are exploits of that. But in general, it's recognized that this is a defense provided by the manufacturers off processing chips.
Another defense is a SLR that's address space layout, random ization. This is where we have randomized memory locations for our functions. If you remember from the demo,
the return address of the function was very important because that's where we wanted our
instruction pointer to land so that we could then have it point to our show code. And so if you randomize that number, it can make the shell code deployment much harder.
Another one that I threw in here is a D bugger intrusion detection system.
This, of course, would have a lot of overhead, but it would have the advantage of looking into the programs and identifying well known payloads shell code before it actually is executed on systems.
Now we're gonna move into the lab portion of our module