2013/11/21 Geyslan Gregório Bem <geyslan@xxxxxxxxx>: > 2013/11/20 Al Viro <viro@xxxxxxxxxxxxxxxxxx>: >> On Wed, Nov 20, 2013 at 09:34:31PM -0300, Geyslan G. Bem wrote: >>> The member 'e_ehsize' that holds the ELF header size is compared >>> with the elfhdr struct size. If not equal, goes out. >>> If 'e_phoff' holds 0 the object has no program header table, so >>> goes out. >>> Ensures the file being loaded has the correct data encoding, checking >>> 'e_ident[EI_DATA]' against 'ELF_DATA'. >>> >>> Besides the checks being in accordance with the ELF Specifications, >>> they increase the binary consistency reducing the use of malformed ones. >> >> This is completely misguided. We are allowed to reject such binaries, >> but what's the point of doing that? > > Viro, First of all, thanks for reply. > > The security (or anti-security) guys are used to mess up with the not checked > header fields for their "benefits": anti-debugging, injection and so on. > > Concerning to 'e_phoff': when it is 0 the check avoids that 'elf_phdr' been read > from a erroneous offset (ELF header). I know that without this check the binary > will goes out anyway. But it reduces wasting cpu cycles. > > Regarding 'e_ident[EI_DATA]': that check also prevents a farther code reading > when the binary, although been the correct arch, is compiled with a different > data encoding (MSB vs LSB). > > So checking besides increase the binary consistency, guarantee some mislead > and fewer cpu cycles. > > -- > Regards, > > Geyslan G. Bem > hackingbits.com Another good reason is that ld does reject such binaries (I hex edit one to hold MSB value in header): uzumaki@hb ~ $ /lib/ld-linux-x86-64.so.2 ./a.out ./a.out: error while loading shared libraries: ./a.out: ELF file data encoding not little-endian After zeroing the phoff: uzumaki@hb ~ $ /lib/ld-linux-x86-64.so.2 ./a.out ./a.out: error while loading shared libraries: ./a.out: object file has no loadable segments I really think that is a way to get a more robust binfmt consistency check. What you think? -- Regards, Geyslan G. Bem hackingbits.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
