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.
Other Memory Exploits
Loading...
Из курса от партнера University of Maryland, College Park
Software Security
727 оценки
Из урока
LOW-LEVEL SECURITY
Low-level security: Attacks and exploits
Познакомьтесь с преподавателями
Michael HicksProfessor
Department of Computer Science
The attack we have just deconstructed is called a stack smashing attack.
The term was coined by the hacker with the handle Aleph One
in his famous 1996 article in Phrack Magazine titled Smashing the Stack for
Fun and Profit, which you can still find online.
The reason for the name is obvious.
The attack overwrites or
smashes important data on the stack to enable illicit actions.
Revisiting the three security properties we briefly discussed in the introductory
lecture, confidentiality, integrity,and availability,
we can see that stack smashing is a violation of integrity.
The attack has corrupted important data in the program and
enabled further corruption of data on the system
by allowing arbitrary code to run on behalf of the attacker.
Stack smashing can also reduce availability
by simply crashing the program or injecting code to make it unresponsive.
For the remainder of this unit we will take a brief look at
other attacks that are a variation of stack smashing.
They too will take advantage of bugs involving the use of memory, but
they will consider memory allocated in different places, and
they may read memory illicitly rather than write to it.
Another sort of attack is a heap overflow attack.
While stack smashing overflows a stack allocated buffer,
you can also overflow a buffer allocated by malloc which resides on the heap.
This code gives an example.
At the top we define a struct, vulnerable_struct,
that has two fields, the first is buff,
a character pointer, the second is the compare function pointer.
Below, we see a function, foo, that takes a vulnerable struct as an argument
along with two character pointer arguments.
To begin, the first line of the function copies one into buff,
the second line copies two past one into buff.
Finally, the third line calls the compare function pointer,
passing buff as an argument and comparing it against the foobar file pointer.
Now you may have noticed that this code is only going to work properly
if the string length of one and
two is less than the maximum length of the buffer into which they were copied.
Otherwise, we will overwrite the compare function pointer.
Just as when we overwrite the return address in a stack smashing attack,
the adversary may be able to control how this overwrite happens and
get the program to run code of his choice.
There are many variants of this basic heap overflow attack.
One variation applies to programs written in C++,
which extends C with support for object orientated programming.
C++ objects consist of data and methods as defined by a class.
Classes support inheritance.
So a method in a parent class can be overrridden by a method defined in
inheriting child class.
C++ supports sub-type polymorphism so
that a child class's object can be used where a parent class object is expected.
As a result, the compiler cannot be sure whether an object declared to have
a type T really does have type T or has a type that inherits from T.
To handle this situation all objects are compiled to have what is called a vtable.
This is an array containing pointers to the code of each of the objects' methods.
The code used to call a method simply indexes the vtable using a fixed offset
that corresponds to the desired method.
Now for this to work, the vtable has to be at a standard location within an object.
Wherever it happens to be, the fields containing the object's data are nearby.
If one of those fields is subject to a buffer overflow,
then the vtable could be corrupted and a method function pointer overwritten.
This is analogous to the situation we just saw with the vulnerable struct in C.
Both this and the earlier attack we saw overflowed a buffer into another field
of the same object.
An alternative is to overflow into an adjacent object.
For example, one containing a function pointer.
This is more challenging because the attacker may need to work
to get the right kind of object nearby the one he can overflow, but it can be done.
A related attack aims to overflow not a program object but
instead the metadata that malloc uses to keep track of heap allocated memory.
Oftentimes the memory just before the pointer returned from malloc contains
a header.
This header may contain pointers, for example,
linking the returned object into a list of allocated data.
Data not currently in use by the program will be linked in a free list instead.
By corrupting this data, an attacker can cause the code implementing malloc and
free to carry out actions to his advantage.
Another sort of attack that's often considered in its own right
is an integer overflow attack.
These attacks rely on the fact that in C, a variable has a maximum value, and
when that value is exceeded, the variable's value will wrap around.
In this case, we're reading in from the network using the packet_get_int function.
Suppose that the adversary has control of the other side of the network and
is sending a very large number.
In fact, suppose the number is 1,073,741,824,
and that the size of a character pointer on our architecture is 4, in other words,
it's a 32-bit architecture.
Obviously nresp is greater than zero, and so
we will malloc a buffer into which we store a response.
Now the adversary has arranged it so that this very large number times 4,
wraps around to 0.
Many malloc implementations will happily allocate a size zero buffer, and
then, the subsequent writes to that buffer are overflowing it.
Of course, just as in all of the other attacks that we have seen, this overflow
may be controllable so that the adversary can inject code or otherwise have his way.
Many of the attacks we have shown so far affect code,
return addresses, and function pointers, but we can also affect data as well.
For example, the attacker might overrun a buffer to modify a secret key
to be one known to him and
therefore he can decrypt future intercepted messages using that key.
He might also modify state variables to bypass authorization checks, for example,
we showed this with the authenticated flag when first introducing the idea
of buffer overflows.
He might also modify interpreted strings,
used as part of subsequent commands sent to other programs.
For example,
server programs that communicate with databases will often do so using SQL.
SQL commands may be overwritten by buffer overflows to get the attacker access to
arbitrary portions of the database.
So far we've just been interested in what happens when you write past the end of
a buffer, but a bug could also permit reading past the end of the buffer,
this might leak secret information.
As an example, consider this program, the program is going to read into buf
from stdin, then it will echo back the number of characters specified.
Here we're reading in an integer, we first read into the buffer and
then call the atoi function to convert the contents of that buffer,
a string, into an integer length.
Next we read in a message.
Finally, we echo back that message by iterating up to the length specified,
printing out the characters one at a time.
Where's the problem?
The problem is that the length that was specified in the first read
may exceed the length of the message provided in the second read.
If it does, it's going to print out characters beyond what was read in.
Here's an example run of this program.
We start the server, enter in a number, and then enter a message.
In this case, the number does correspond to the length of the message and
the program echoes back the message as expected.
Here the number is slightly less than the length of the message and,
as expected, fewer characters are returned.
Here, the number is greater than the length of the message, and
we can see that extra data is printed out beyond what was entered.
This data is leaked.
It was whatever read in previously.
The Heartbleed bug is an example of a high profile buffer overflow,
discovered in early 2014, that involves reading data rather than writing it.
By some estimates, Heartbleed affected nearly 600,000 servers on the Internet.
The bug was in the implementation of the so-called
heartbeat functionality of the SSL protocol.
This functionality allows a client to send a heartbeat message to the server,
asking it to respond back to confirm the connection is still active.
The heartbeat message contains a length field
that indicates the length of the portion of the message to echo back.
The bug in the SSL server was that it did not check the length was accurate.
In fact, it could be much longer than the heartbeat message itself.
By specifying a long length, the attacker could get the buggy server to
read beyond the buffer containing the heartbeat message and
therefore, return whatever was in nearby memory.
Depending on the activities of the server prior to the overflow, nearby memory could
contain things of interest to the attacker, such as passwords,
cryptographic keys, or other items specific to the server using SSL.
Another interesting memory bug occurs when dealing with stale memory.
A dangling pointer bug occurs when a pointer is freed but
the program continues to use it.
An attacker may be able to arrange for the freed memory to be reallocated, and
then under his control prior to the program using
the pointer that was previously freed.
So here's an example at the bottom.
We have a struct again with a compare function pointer in it.
Here we allocate it, and then free it.
Now, suppose some time goes by and malloc is called and it reuses the memory
that we just freed, allocating it now to this buffer pointed to by q.
q stores to it some random value.
Worse, maybe the attacker can control what was stored to the value using q.
Now later on, the program reuses p despite the fact that it freed it
by calling the compare function pointer.
And in this case, it has to reference a dangling pointer and
is going to go straight to the memory that the attacker put there.
In fact, it was just this sort of bug that played a huge role
in the attack that China had on Google back in 2010.
An invalid pointer was accessed after an object was deleted in Internet Explorer.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
