As a hard and fast rule you can consider any crash where we are not
intentionally trying to crash (using __debugbreak(), DebugBreak(),
RaiseException() or CHECK ) as probably exploitable.
If you think a little bit about a crash you might be tempted to think
it is not exploitable, but is easy to get fooled. For example a crash
resulting from a null pointer deference. How can you exploit that?
For an example I have cooked a little program:
================================================
#include "stdafx.h"
#include "stdlib.h"
bool ComputeIfDog() {
// Long computation + internet request Ommited for convenience.
return true;
}
bool IsADog() {
static bool p = ComputeIfDog();
return p;
}
// Command line params: <size_to_alloc> <index_to_write_zero_to>.
int _tmain(int argc, wchar_t* argv[]) {
if (argc != 3)
return 1;
IsADog();
int rows = _wtoi(argv[1]);
int index = _wtoi(argv[2]);
int* buffer = (int*)malloc(sizeof(int) * rows);
if ((index < 0) || (index >= rows))
return 1;
buffer[index] = 0;
wprintf(L"hello, I am a %s .\n", IsADog()? L"dog" : L"cat");
return 0;
}
======================================================
the program takes two cmdline params, the first is a size to alloc an
int array and the second one is an index in the array to set to zero.
Operating properly, (for example calling it with "50000 0" the program
outputs "Hello, I am a dog".
But if you call it with "1000000000 0"
It crashes. The crash is
"Unhandled exception at 0x00411562 in null_exploit.exe: 0xC0000005:
Access violation writing location 0x00000000."
Hmmm, null pointer deref... can it be exploited?
Sure it can, on XP try it with "1000000000 1073240" and watch the
output.
It would be easy to just say, well put checks in the result of all
mallocs or news, but what about this call? std::vector<T>::reserve(n)
This kind of exploits and the use of stl is the reason why have this
code:
int OnNoMemory(size_t memory_size) {
__debugbreak();
}
_set_new_handler(&OnNoMemory);
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
