When we talk about memory,
we often refer to memory attacks as buffer overflow attacks.
These attacks frequently develop malware
explaining various attributes and functions
of the primary memory core within the computer system.
When we think about buffer overflow attacks,
I really want you to get in your mind that you have memory,
what's inside your computer?
We're not just talking about regular storage memory,
we're talking about memory as a whole.
And when that memory overfills,
we can commonly see different aspects within our transmission of a system
to system communication being let over done or overfilled through the process.
So let's kind of take a step back and look at this. OK? Within a normal system,
we have our memory within our computer system. And in that memory, we write data.
Now, I want you to imagine that I'm encrypting data.
I'm going from one network over to one server and we're going
to process that data to make sure that that data isn't compromised.
I'm going to encrypt it.
So I send my encrypted data from my operating system over
to a server and it's encrypted across the entire pathway.
You think you're good, you've encrypted your data.
However, as it's
to the memory of the server, we must first unencrypt it,
it's a standard process within a server.
We've unencrypted that data and we start writing it to the memory.
This is where a buffer over plaque. A buffer overflow attack takes place.
The unencrypted data is in trying to write to the memory of the server
as a malicious actor, I can write to that memory core.
And unlike a normal operating system where I filled up
the memory and it stops writing that memory then overflows.
So that encrypted traffic that is now unencrypted is
now spilling out of our memory within our server.
And we refer to this as a buffer overflow attack. Why is this important?
If I'm trying to log into a server and I'm trying
to gain access to that server or to that web page,
I normally put forward a username and password.
Now that username and password is usually done
encrypted and it's sent to the server,
the server verifies it and then it lets me gain access
just like before it's going to let me gain access.
But as it's writing to the memory, it's actually getting spilled out.
So malicious actor that is using a buffer overflow attack
could actually see that username and password in plain text,
but it doesn't just stop username and passwords.
It could be critical vital information.
The only good piece is not all that information or data is being spilled out at once.
You're only getting tidbits up here and there,
which means you can log into the system and be 100% foolproof.
But the next person could it their data,
their username and password to accidentally spill out,
giving that uh compromised data to the malicious actor.
When we talk about attacks directed at heat memory,
we're usually talking about the complexity of the attack being a
little bit more complex in nature and not always successful.
Either this heap attack takes care
the data within a normal buffer overflow attack and overwrites it.
So instead of writing the memory,
we're then overwriting the memory with what we want to put in.
Not just reading the data, as we normally see with an energy overflow attack.
A normal system only uses orbits or bytes of information at a time.
If I provide more data ie more than that four bits is capable of than I've
the integer amount of the data being rigged to the system.
This then closes a vulnerability to the system which
then provides us with an integer buffer overflow attack.
When we talk about buffer overflow attacks,
we normally need to understand the mitigation that goes
in line with how to defend against such attacks.
One such animation technique is simple input validation that we've
seen this time and time again on websites on programs,
we're validating the input.
Obviously, if I'm doing a number only system, like you might see in a calculator.
I don't want the user to be able to provide letters as well.
Common input and input validation reflects that we're
going to stay away from those common slashes,
those semi colons,
those specific integers or the specific keystrokes that
would allow for somebody to program a computer.
We also have something that's called lease privilege.
The principal lease privileges provides us only the minimal
needed data for a user to have access to.
Obviously, if I'm a janitor,
I only need access, maybe to calendar, maybe some office word documents,
maybe some basic principles of,
of the operating system or of the program that limits my availability.
I'm not going to give a janitor full access to my servers and configuration access.
This is the concept of least privilege.
At the same time, I don't want to give my operating system guys my,
it guys access to the ce OS information
and I don't want the CEO to have access to my I T's access to configuration of servers.
We call this concept the concept of least privilege.
When we talk about secure coding,
we're securely coding our programs and our applications.
We want the coding to be secure. We want it to handle errors properly.
We won't want it to be just something that I found online.
Maybe ChatGPT wrote me a program code that's not
very secure because anybody could have written anything in there
and I want it to be secure from the start
meaning I'm not doing security before or excuse me,
after the coding process, I'm doing the secure coding during the process.
Secure coding in its full functionality is a very robust topic.
So I just want you to understand that we need secure
coding as our mitigation technique for a buffer overflow attack.
We can also do runtime application, self protection within a runtime self
app, uh runtime application, self protection or rasp
we're really kind of taking this aspect of, hey,
can I run this program and it's protected while it's running the process?
We can do Stack canaries which are pretty self explanatory address space
layout randomization where we're laying out
the randomization of the address space.
We're not going to put everything in one spot.
We're going to randomize where it is we're at the code sign,
meaning the developer actually signs the code that we're utilizing,
meaning that if something comes into play or a
different code comes into play and we don't know where
it came from that needs to have a signer to that specific code so that we can verify the
aic
of that code. And of course, the last one is heap randomization.
We're going to randomize that heap.
And so it doesn't necessarily be for front and center on our aspect
of our memorization where somebody has full access to it right off the
getrandom
within the process.