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.
Format String Vulnerabilities
Loading...
Из курса от партнера University of Maryland, College Park
Software Security
769 оценки
Из урока
LOW-LEVEL SECURITY
Low-level security: Attacks and exploits
Познакомьтесь с преподавателями
Michael HicksProfessor
Department of Computer Science
[SOUND]
The final category of buffer overflow style attack we will consider is
called a format string attack.
It is named for the format strings used by the printf family of
library functions in the standard C library.
A format string is typically the first or
one of the first arguments to a printf style function and
the remaining variable number of arguments comprise the data to be printed.
Format strings use what are called format specifiers to indicate how
data should be formatted.
For example, the code snippet shown here prints out a record consisting of
an individual's name and age.
The first format specifier applies to the first argument following
the format string, and the second specifier applies to the second argument.
In this case, the first argument is a string and the second is an integer.
There are also many other kinds of specifiers too.
Now, let's see how a simple misunderstanding of how
format strings should be used, can lead to a serious vulnerability.
Now, we might wonder,
what's the difference between this function and this function?
We can see that on the first two lines the functions are identical.
They allocate a character buffer on the stack.
And they call fgets to read into it.
The difference is on the third line.
The first function calls %s as a format string prior to printing buf.
Whereas the second function forgoes using a format string altogether and
just places buf there.
Now we might think to ourselves, buff is just a string in both cases.
So why do I need the format string?
Well, the important part is that buff might itself contain format specifiers.
In the first case,
if it does, those specifier will just be printed out to the screen.
In the second, those will be interpreted.
If the attacker controls the format string then the interpretation of
those format specifiers can work to his advantage.
So let's look at how printf is implemented and see how that might happen.
Here we see a call to printf.
It's going to print out i and its address using the %d and %p format specifiers.
The first is for printing an integer.
The second is for printing out a pointer.
Here's what the stack might look like with the top most address range to the right,
and the stack growing from right to left as usual.
We can see the arguments on the stack.
First of all, the &i argument.
The i argument.
And the format string, pushed in reversed order.
Printf takes a variable number of arguments and
pays no mind to where the stack frame actually ends.
It presumes that when you called it,
you passed in at least the number of arguments specified in the format string.
Here we have %d which corresponds to the argument ten.
And here we have %p that corresponds to the argument &i.
So everything is well.
Now let's go back to our vulnerable function.
Suppose we passed in the format string %d %x.
And notice that there are no additional arguments provided.
In this case, the stack will look as follows.
We'll have just pushed the format string argument and that's all.
Now when printf goes to interpret that string, it will read from the caller stack
rame, frame the %d portion and then we'll read again for the %export portion.
Let's think about some other format strings and what might happen.
This format string will print out the four bytes above the saved instruction pointer.
Why is that?
Well it turns out that printf ignores any spaces between the percent and
the format character that's used in the specifier.
In this case%d.
In this case, it's going to print out the byte pointed to by this stack entry.
So it's going to look one pass the saved eip,
interpret that four bytes as a pointer, go to that memory address and
then print out the entire content until it reaches an ultimanator.
This will print out a series of stack entries as integers and
this format string will print in, print them out as hex.
Now here is the really terrible one.
This one will actually write the number three toward the address pointed to by
the stack entry.
Why is that?
Well, %n is a format specifier that is used to write the progress that printf has
made in printing out to the output stream.
In this case, it will have printed 3 characters, 100,
and so it will print the number 3 to whatever the argument is on the stack.
It's expecting to receive an integer, right, for corresponding to the %n.
But it's not actually going to get one.
Instead it's going to override the stack entry instead.
And as you might suspect, this is going to allow the attacker to do
a remote code injection in certain circumstances.
So you might ask yourself, why is a format string attack like a buffer overflow.
Well, we should think of it as a buffer overflow in the sense that
the stack itself can be viewed as a kind of buffer.
That is, all of the arguments defined by a function define a kind of
buffer and bounds.
The size of that buffer is determined by the number and
size of the arguments passed to the function.
So providing a bogus format string thus induces the program to
overflow the buffer as defined by the arguments.
This vulnerability has been around for
quite a while and continues to happen despite people knowing about it.
Now that we have seen the wide variety of buffer overflow style attacks that exist,
it's time to trade our black hat for a white one.
To see about how to defend against them.
In our next unit we will step back and
look more carefully at what these attacks have in common.
Then we will look at a variety of different defenses and
evaluate their effectiveness.
In essence, we will chronicle the cat and mouse game played by attacker and
defender over the last couple of decades.
By the end, we will see that unfortunately,
when programming in C the attacker still largely has the upper hand.
Fortunately, it is far more difficult today to generate an exploit than it
use to be, and new methods for
avoiding buffer overflow vulnerabilities are being developed.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
