When we talk about memory, we often refer to memory attacks as buffer overflow attacks.
These attacks frequently develop malware exploiting 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 system
to system communication being let overdone or overfilled.
Through the process.
So let's kind of take a step back and look at this.
Okay.
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 writing 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 overflow.
Buffer overflow attack takes place.
The unencrypted data is then 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 can actually see that username and password
in plain text.
But it doesn't just stop at 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.
They're only getting tidbits of here and there, which means you can log into the system and be 100%
foolproof.
But the next person couldn't.
Their data, their username and password could accidentally spill out, giving that compromised data
to the malicious actor.
When we talk about attacks directed at heap 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 corrupted 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 within an integer overflow attack, a normal system only uses
four bits or bytes of information at a time.
If I provide more data, i.e. more than that four bits is capable of than I've exceeded the integer
amount of the data being written to the system.
This then poses 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 intimidation technique is simple input validation.
We've seen this time and time again on websites on programs where 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 semicolons, those specific integers, or
those specific keystrokes that would allow for somebody to program a computer.
We also have something that's called least privilege.
The principle of least privilege 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 CEO's information,
and I don't want the CEO to have access to my its 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 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 going to 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, there needs to have a signer to that specific code so that we can verify the authenticity
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 more front and center on our aspect of our memorization to where somebody
has full access to it right off the get go.
We want it to be randomized within the process.