Informative Information for the Uninformed | ||||||||||||||
|
||||||||||||||
Next: Consistent Handling of Fixup
Up: Differences in Relocation Processing
Previous: Self-updating Relocation Blocks
Integer Overflows in Size CalculationsA potential source of mistakes that could be made when processing relocations has to do with the handling of the SizeOfBlock attribute of a relocation block. There is a potential for an integer overflow to occur in applications that don't properly handle situations where the SizeOfBlock attribute is less than the size of the base relocation structure (which is 8 bytes). In order to calculate the total number of fixups in a section, it's common to see a calculation like (Block->SizeOfBlock - 8) / 2. However, if a check isn't made to ensure that SizeOfBlock is at least 8, an integer overflow will occur. If this happens, the application processing relocations would be tricked into processing a very large number of relocations. An example of a test for this issue is shown below:
static VOID TestIntegerOverflow( __in PPE_IMAGE Image, __in PRELOC_FUZZ_CONTEXT FuzzContext) { PRELOCATION_BLOCK_CONTEXT EvilBlock = AllocateRelocationBlockContext(0); EvilBlock->SizeOfBlock = 0; EvilBlock->Rva = 0x1000; PrependRelocationBlockContext( FuzzContext, EvilBlock); } In this example, a relocation block is created that has its SizeOfBlock attribute set to zero. This is invalid because the minimum size of a block is 8 bytes. The results of this test against different applications are shown below:
|