Below is an example section header with the relevant pieces changed. This 64-bit value is actually read from the binary’s section header table and is easily controlled by the attacker. We can see this value is an int which is read in directly from the program itself and then used without any validation. After some reversing we can detect where the r14 value has come from and can also determine what is causing the out of bounds access in the second crash call readint64 Here we see the program is crashing on a null check ensuring the supplied value is not 0 and in another scenario it is crashing due to an invalid string being passed into strlen.
=> 0x7ffff3491d16 : movdqu xmm4,XMMWORD PTR There are two initial crashes shown below: RAX: 0x7fffbaf9fab0 -> 0x101000101010100Ġx7ffff65c96af: mov r14d,r15d user_controlled_intĠx7ffff65c96b2: mov rax,QWORD PTR This is then used later, causing the program to access memory out of bounds and leads to the vulnerable conditon. During the parsing of ELF section headers, there is a user controlled size passed in that is not validated to be correct. Hopper is a popular disassembler used for analysis of disassembly of various binary formats. An attacker can craft an ELF file with sepecific section headers to trigger this vulnerability. A specially crafted ELF file can cause attacker controlled pointer arithmetic resulting in a partially controlled out of bounds write. An exploitable out of bounds write vulnerability exists in the parsing of ELF Section Headers of Hopper App.
0 kommentar(er)
