Обратите внимание, что это зависит от платформы, и мой пример слишком упрощен. В основном это сводится к тому, что менеджеры кучи имеют связанные списки, которые могут быть переполнены, и вы можете использовать указатели связанных списков для перезаписи случайных частей памяти процесса.
Представьте, что у меня есть наивная реализация кучи, блоки управления которой выглядят так:
struct HeapBlockHeader
{
HeapBlockHeader* next;
HeapBlockHeader* prev;
int size;
// Actual heap buffer follows this structure.
};
Когда освобождается куча, этот блок управления возвращается в список освобожденных блоков, изменяя указатель следующего / пред. Если я переполню буфер кучи, я могу перезаписать указатели в следующем блоке управления данными, которыми я управляю. Предположим, я переопределяю эти ссылки, чтобы указывать на указатель на код (возможно, только в буфере, который я переопределил) и на адрес возврата функции в стеке. Когда менеджер кучи пытается связать блок обратно в освобожденный список, он фактически перезапишет адрес возврата в стеке указателем на код, которым я управляю.
В этой статье представлен хороший обзор атак переполнения кучи:
http://www.h -online.com / безопасность / особенности / A-Heap-оф-Risk-747161.html
В этой статье описываются некоторые меры защиты, которые были добавлены в менеджер кучи Vista для предотвращения атак такого типа:
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Marinescu.pdf
EDIT: при возможности запуска кода из кучи, да, это возможно. Многие платформы теперь делают память кучи неисполняемой по умолчанию, что повышает барьер для запуска произвольного кода. Однако вы все равно можете выполнить атаку в стиле «переход к libc» - переписать адрес возврата в известную функцию, которая будет выполнимой.