NULL pointer dereference in chap::Linux::ELFImage about chap HOT 6 CLOSED

I replied too soon when I confirmed your findings, or rather not specifically enough. That file definitely does cause chap to crash due to an invalid memory reference, but the pointer in question is not NULL.

The issue as it turns out is that the given core file has an invalid value for e_phnum in the ELF header.
The value should be 0x21 based on an inspection of the file that shows that the first program header
starts at 0x40 (based on e_phoff) and each entry is of size 0x38 (based on e_phentsize) and then looking starting at offset 0x40 in the file there are actually 33 (0x21) apparently valid program headers. In fact, the value for e_phnum is 0x4021.

0:    10102464c457f                0        1003e0004                0

20: 40 0 38004000000000 4021

So then what happens is that chap attempts to process 0x4021 program headers and one of these looks like an ill-formatted PT_NOTE section where the first name length is bogus, and when added to the start of the PT_NOTE section yields an invalid address.

Note that readelf and file also have trouble with this particular core but handle it more gracefully:

bash-4.1$ readelf -l null_ELFImage > null_ELFImage.readelf
readelf: Error: Unable to read in 0xe0738 bytes of program headers

-bash-4.1$ file null_ELFImage
null_ELFImage: ERROR: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './a.out'error seeking (Invalid argument)

I will make the change to harden chap to not crash in such a case but am curious about how a file with a bogus e_phnum got generated.

from chap.

That file also apparently had one strange case with a tiny PT_LOAD area near address 0. I'm not sure that these bugs introduced by fuzzing, particularly the one with e_phnum being invalid, will ever be seen on a real core but for now I have hardened chap to work around them and to report if an e_phnum value is considered to be invalid.

-bash-4.1$ chap null_ELFImage
Program header at offset 0x778 has unexpected alignment 0x695f00000000.
Perhaps the e_phnum value in the ELF header is invalid.
null_ELFImage is truncated.
It has size 495616 which is smaller than minimum expected size 18299417742827209744.
Many commands may be disabled or inaccurate as a result.
chap>

from chap.

Thank you for reporting this! I have confirmed your findings. If you would like, I can fix it sometime today or if you would prefer to submit a pull request I can review it.

from chap.

Hello,

Bug titles are based on names detected in ASan.

As you said, the file I upload is not a normal file.

This is a file generated by Fuzzing.

Thanks.

from chap.

Hello,

Maybe, ordinary users have no problems with program execution and functionality. (Because it is not a normal file)

However, it can be used by a malicious attacker(hacker).

And, it is necessary to make the software robust and create a safe environment for users.

various libraries(ex:radare2,readelf) that deal with ELF files are fixing these problems.

Ex) radareorg/radare2#8813

Thanks.

from chap.

Thanks for the example and for filing the issue. I agree that it is worthwhile to make chap more robust.

from chap.