This course we will explore the foundations of software security. We will consider important software vulnerabilities and attacks that exploit them -- such as buffer overflows, SQL injection, and session hijacking -- and we will consider defenses that prevent or mitigate these attacks, including advanced testing and program analysis techniques. Importantly, we take a "build security in" mentality, considering techniques at each phase of the development cycle that can be used to strengthen the security of software systems. Successful learners in this course typically have completed sophomore/junior-level undergraduate work in a technical field, have some familiarity with programming, ideally in C/C++ and one other "managed" program language (like ML or Java), and have prior exposure to algorithms. Students not familiar with these languages but with others can improve their skills through online web tutorials.
Code Injection
Loading...
Из курса от партнера University of Maryland, College Park
Software Security
795 оценки
Посмотрите похожие видео
В Coursera собрались лучшие преподаватели мира. Вот несколько рекомендаций лично для вас:
Из урока
LOW-LEVEL SECURITY
Low-level security: Attacks and exploits
Познакомьтесь с преподавателями
Michael HicksProfessor
Department of Computer Science
[SOUND]
Now let's look at the main idea of code injection using a buffer overflow.
Recall our function func, and in this case, using sprintf to copy into buffer.
There are two main challenges for code injection.
The first is somehow using the program to load your own code into memory.
And the second is somehow getting the instruction pointer to point to it, so
that that code can be executed.
So let's look at the first challenge, loading code into memory.
The first thing to keep in mind is that this code must be the machine code
instructions that that machine is prepared to run.
In other words, it's not going to be C source code, but instead,
it's going to be the actual assembly language for the target architecture.
Moreover, it can't be just any assembly language.
We have to be con, careful about how we construct it.
So for example, it cannot contain any all-zero bytes.
Why is this?
Well, strcpy, sprintf, gets, scanf, and various other unsafe calls
that we might like to exploit will only copy data that doesn't have zeros in it.
That is, it will copy from the start of a source buffer
up until it reaches zero and then stop.
Therefore if we want to inject a lot of code,
we have to make sure that all of that code contains no zeros.
Next, we need to be careful that the code is complete.
It can't assume that it can use the loader to say
resolve memory addresses inside of the program.
Instead, it has to be completely self-contained.
What code should we try to run?
Well, we want to try to run a general purpose shell in the best case.
A general purpose shell is a command-line prompt
that provides the attacker general access to the system.
You may want to do other things with the code you inject, but
this is sort of the best case.
Code that launches a shell as part of an attack is called shellcode.
Here's what the shellcode you might like to write might look like.
It's a simple function that calls execve,
which effectively transforms the current program into the one given as an argument.
In this case, the argument is /bin/sh, a shell.
Here's some assembly for this shell code.
If we look at the first instruction, this is what it might look like as a string.
This would be the string that you provide as part of your input.
The second challenge is getting the injected code to run.
Just because we loaded the code in doesn't mean we can get the pointer, the program,
to jump to your code whenever you like.
Moreover you don't know precisely where you code
is with respect to the instruction pointer.
Somehow, we have to get it at the start, and start running.
Now, recall the memory layout summary for the calling and returning from functions.
How could we use this setup to our advantage to inject code?
Here's the key.
The very last step jumps back to the location of the return address,
which was saved on the stack.
Therefore, we can store the address of our code at that location.
And therefore, get the program to jump to that code.
That's the main trick.
Here's what it looks like visually.
We load in the address of out code over top of eip saved on the stack.
Therefore, when the function returns, it's going to return exactly to that location
and then start running the code.
Now the next question is, what address should we put there?
How will we know what the address is?
Well, maybe thinking of the question another way, we can ask,
what if we get the address wrong?
If we pick the wrong address and jump to some other location.
Most likely, the CPU will panic because it will reach an invalid instruction,
therefore crashing the program.
Another challenge that adversaries sometimes face is finding the return
address.
Now, if the adversary knows the code that he is trying to attack and knows exactly
where the buffer overrun is, he might know exactly where the buffer is with respect
to the frame pointer, and therefore where the return address is located.
Therefore, he knows what the location is to overwrite to get his code to be run.
On the other hand, the adversary may not have access to the code and
may not know how far an overrun buffer is from the saved frame pointer.
One approach is trial and error.
Just try a lot of injected values on a running server until something works.
But of course, the address space is quite large and maybe this won't really work.
On the other hand, without address randomization, which is
something we'll discuss later, the stack always starts from the same fixed address.
The stack will grow, but
usually it doesn't grow very deeply unless the code is heavily recursive.
This reduces the search base dramatically.
Another thing the adversary can do is use what is called a nop sled.
A nop is a single-byte instruction that just moves to the next instruction.
If the adversary sticks a bunch of nops as padding, prior to his own code,
then jumping anywhere in that nop sled will work.
Now we can improve our chances by a factor of a number of nops.
So, putting it all together.
Here's what all of the injected adversarial code might look like.
This part labeled padding has to be something, because we have to start
writing wherever the input to gets, or sprintf, or strcpy begins.
But, when the program returns to the picked location,
it'll hit the nop sled and start running our malicious code.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
