Part 4 Defenses
Video Activity
This lesson covers mitigations, countermeasures and defenses. Three major defenses are covered in this unit: • Dangerous functions and their safer equivalents • Static format strings • Safe memory allocation Processor (aka non programmer) defenses are also covered in this lesson. These include: • No execute (NX) bit • Address space layout randomiza...
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 »
Video Description
This lesson covers mitigations, countermeasures and defenses. Three major defenses are covered in this unit: • Dangerous functions and their safer equivalents • Static format strings • Safe memory allocation Processor (aka non programmer) defenses are also covered in this lesson. These include: • No execute (NX) bit • Address space layout randomization (ASLR) • Debugger Intrusion Detection System (IDS)
Video Transcription
00:04
Hello and welcome to the cyber very secure coding course. My name is Sonny Wear, and this is buffer overflows, medications, countermeasures and defenses.
00:14
So first, the defense's overview. We're gonna look at three main areas,
00:20
dangerous functions, and they're safer equivalent. There's a reference table that we're gonna go through
00:26
static format strings. This is where we're going to use static format strings for the display of our values instead of arguments.
00:35
And then
00:36
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.
00:49
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.
01:07
And this continues on down the list.
01:11
Now, please realize that the the safer functions that are listed on the right
01:18
may not actually be called these names on your particular platform. Solaris platform calls them by a little bit different name.
01:29
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,
01:46
this is going to address those formats string attacks that we saw.
01:49
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
02:02
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
02:15
safe memory allocation. This is an example of a function that actually performs
02:23
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
02:38
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
02:52
now. I also wanted to give a nod to the non programmer defenses because there are quite a lot out there
03:00
from a processor or chip manufacturer perspective. There's theme no execute bit or in ex bit. It's also known a step.
03:08
What this does is it essentially prevents the stacks smashing
03:15
that we saw being done in the demo, so it prevents the execution of show code on the stack.
03:23
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.
03:38
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,
03:53
the return address of the function was very important because that's where we wanted our
04:00
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.
04:14
Another one that I threw in here is a D bugger intrusion detection system.
04:18
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.
04:39
Now we're gonna move into the lab portion of our module
Up Next
Instructed By
Similar Content
