I found a repeatable bug in ltrace version 5 and 4. I contacted debian developers responsible for ltrace but they don't seem interested. I believe this only to be denial of service but im willing to be found wrong. The problem begins on line 524 of elf.c of ltrace package. const char *name; ... name = lte->dynstr + sym.st_name; ... Obviously you can control value of sym.st_name and lte->dynstr by modifying the ELF binary and thus control value of 'name' variable. 'name' is then used in ... in_load_libraries(name, lte); ... Now depending on the value of 'library_num', which is set using the '-l' flag at runtime, the code can go one of two ways. Either a memory dereference happens in elf_hash() or the code returns 1, (no -l specified), and goes to add_library_symbol() and strlen() is called with 'name' as its argument, which is a length argument to malloc(). I toyed with this a bit, because I can partly control the amount of memory that gets malloc'd. It would take a very funny situation to do anything with the heap on my x86 linux box, not sure about other archs/systems. Contact me if you need a POC elf object. Hopefully gentoo will respond
thanks for your report. setting status and cc'ing herd. A PoC would be nice if you can create one.
http://structsoftware.net/elf-crashes-ltrace Its a binary I was fuzzing, so it actually doesn't execute properly, and interestingly enough throws readelf into an infinite loop when reading some of its sections. You can control the value of sym.st_name at offset 0x19e in the object. If you break in GDB on line 524 of elf.c %ebx=lte->dynstr and %ecx=sym.st_name.
Why is this product=Gentoo Security? could someone enlighten me about possible security impact?
(In reply to comment #3) > Why is this product=Gentoo Security? > could someone enlighten me about possible security impact? > yikes, I forgot about this. I only marked security because I didn't have the time to check whether it was more or not. I'm pretty convinced its only DOS and can be treated that way. Sorry for delay :)
(In reply to comment #0) > Obviously you can control value of sym.st_name and lte->dynstr by modifying the > ELF binary and thus control value of 'name' variable. 'name' is then used in Are you saying you can crash ltrace by executing a specially crafted ELF? Or did I misunderstand something here?
Please take the bug upstream or reopen if you can answer the questions raised.
yes you can crash ltrace at two different spots by tracing a specially crafted ELF
(In reply to comment #7) > yes you can crash ltrace at two different spots by tracing a specially crafted > ELF User-assisted client side DoS is not handled as a security issue, please file a bug upstream.
