No description provided by source.
Many shell users, and certainly a lot of the people working in computer forensics or other fields of information security, have a habit of running /usr/bin/strings on binary files originating from the Internet. Their understanding is that the tool simply scans the file for runs of printable characters and dumps them to stdout - something that is very unlikely to put you at any risk. It is much less known that the Linux version of strings is an integral part of GNU binutils, a suite of tools that specializes in the manipulation of several dozen executable formats using a bundled library called libbfd. Other well-known utilities in that suite include objdump and readelf. Perhaps simply by the virtue of being a part of that bundle, the strings utility tries to leverage the common libbfd infrastructure to detect supported executable formats and "optimize" the process by extracting text only from specific sections of the file. Unfortunately, the underlying library can be hardly described as safe: a quick pass with afl  (and probably with any other competent fuzzer) quickly reveals a range of troubling and likely exploitable out-of-bounds crashes due to very limited range checking. In binutils 2.24, you can try: $ wget http://lcamtuf.coredump.cx/strings-bfd-badptr2 EDB Mirror: http://www.exploit-db.com/sploits/35081 ... $ strings strings-bfd-badptr2 Segmentation fault ... strings: segfault at 4141416d ip 0807a4e7 sp bf80ca60 error 4 in strings[8048000+9a000] ... while (--n_elt != 0) if ((++idx)->shdr->bfd_section) elf_sec_group (idx->shdr->bfd_section) = shdr->bfd_section; ... (gdb) p idx->shdr $1 = (Elf_Internal_Shdr *) 0x41414141 In other words, this code appears to first read and then write to an arbitrary pointer (0x41414141) taken from the input file. Many Linux distributions ship strings without ASLR, making potential attacks easier and more reliable - a situation reminiscent of one of CVE-2014-6277 in bash . Interestingly, the problems with the utility aren't exactly new; Tavis spotted the first signs of trouble in other parts of libbfd some nine years ago . In any case: the bottom line is that if you are used to running strings on random files, or depend on any libbfd-based tools for forensic purposes, you should probably change your habits. For strings specifically, invoking it with the -a parameter seems to inhibit the use of libbfd. Distro vendors may want to consider making the -a mode default, too.  Obligatory plug: http://code.google.com/p/american-fuzzy-lop/  http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html  https://bugs.gentoo.org/show_bug.cgi?id=91398