#11 corrupt ELF headers crash ht

[Rohan]

I have a certain file on my linux box which causes the
following error when opened:

in file htendian.cc, line 89: assertion failed: 0

All other files open just fine. This is ht-0.7.4.

I unfortunately can't provide the file due to copyright
restrictions, but basically it's a UPX compressed ELF
with all of the bytes preceding the second ELF header
removed.

[Rohan]

Logged In: YES
user_id=816828

Some backtracing later, seems the ELF header was corrupt
(i.e., since it's compressed) in such a manner that the
endianess wasn't a legal value, and when this happens
elf_shared->byte_order is never set. So, create_host_int
was getting passed garbage in the from_endianess variable.

The attached patch causes htelf.cc to assume that ELF files
with corrupt headers are LSB. Of course this isn't always
right (maybe a better solution would be assuming byte order
is same as host system?), but at least ht will no longer
crash when attempting to open corrupt ELFs :-)

[Rohan]

patch to allow editing ELFs with corrupt byte order info.

[Rohan]

Logged In: YES
user_id=816828

OK, after the last bug I did some testing and in general,
the ELF header parsing seems a little unsafe.

Creating a 4 byte file containing only the 4 'magic' ELF
bytes results in a segfault.
Creating a random file, first 4 bytes of which are 'magic'
ELF bytes, results in a segfault or severe memory leak.

Can ELF header parsing please be fixed up for 0.8? Also,
because of errors like these (which may well exist for other
file types recognised by ht), there should _definitely_ be
an option to open a file without attempting to parse
'special information' - i.e. to edit it as pure hex.

So, it looks like ht _will_ still crash when attempting to
open most corrupt ELFs :-(

[Stefan Weyergraf]

Logged In: YES
user_id=3434

I would even go so far as to say that ELF parsing code just
sucks. That's one reason for us to rewrite HT (should get
0.9). Anyways.
Our policy for broken files is to detect breakage and then
ignore this information.
So in this case (ELF byte-order corrupted), further parsing
should not happen.
A warning should probably be issued to the log window however.
This will be in 0.8. Thanks.

[Stefan Weyergraf]

Logged In: YES
user_id=3434

Changes are now in CVS. This should fix some of the
described bugs. Please check it out. I will do a complete
ELF code review this or next week.

[Rohan]

Logged In: YES
user_id=816828

OK, here's some behaviour I've noticed in the recent CVS (i.e. since you posted 'Changes are now in CVS').

If the first four bytes are ELF magic AND byte 5 and 6 are valid AND file is at least 16 bytes long, then file is parsed as an ELF regardless of the remaining contents of the file.

The program continues to function correctly regardless of what is exclusively between byte 6 and e_shnum.

If e_shnum is invalid, the program seems to freeze and leak memory continually.

If e_shstrndx is invalid, the program segfaults.

I'm no ELF expert, so my little bug tests aren't as thorough as they could have been. Particularly, when I talk about 'invalid' values, I mean values that I 'guessed' would be incorrect, given what they seem to represent. I could easily have missed something. Also, I only tested till the end of ehdr; phdr could have bugs too.

As a side note, the original file which resulted in this bug report now opens just fine, and is not parsed as an ELF. Progress :-)