#11 corrupt ELF headers crash ht

open
None
5
2004-01-13
2004-01-13
Rohan
No

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.

Discussion

  • Rohan

    Rohan - 2004-01-13

    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

    Rohan - 2004-01-13

    patch to allow editing ELFs with corrupt byte order info.

     
  • Rohan

    Rohan - 2004-01-13
    • priority: 5 --> 2
    • summary: failed assertion (htendian.cc) --> corrupt ELF headers crash ht
     
  • Rohan

    Rohan - 2004-01-13
    • priority: 2 --> 5
     
  • Rohan

    Rohan - 2004-01-13

    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.

     
  • Stefan Weyergraf

    • assigned_to: nobody --> steveman
     
  • Rohan

    Rohan - 2004-01-15

    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 :-)

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks