don't run 'strings' on untrusted files

Many shell users, and certainly most 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, say:

$ wget http://lcamtuf.coredump.cx/strings-bfd-badptr2
...
$ strings strings-bfd-badptr2
Segmentation fault
...
strings[24479]: segfault at 4141416d ip 0807a4e7 sp bf80ca60 error 4 in strings[8048000+9a000]
...
      while (--n_elt != 0)
        if ((++idx)->shdr->bfd_section)                                ← Read from an attacker-controlled pointer
          elf_sec_group (idx->shdr->bfd_section) = shdr->bfd_section;  ← Write to an attacker-controlled pointer
...
(gdb) p idx->shdr
$1 = (Elf_Internal_Shdr *) 0x41414141

The 0x41414141 pointer being read and written by the code comes directly from that proof-of-concept file and can be freely modified by the attacker to try overwriting program control structures. Many Linux distributions ship strings without ASLR, making potential attacks easier and more reliable - a situation reminiscent of one of the recent bugs in bash.

Interestingly, the problems with the utility aren‘t exactly new; Tavis spotted the first signs of trouble 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.

The GNU Binutils are a collection of binary tools. The main ones are:

ld - the GNU linker.
as - the GNU assembler.
But they also include:

addr2line - Converts addresses into filenames and line numbers.
ar - A utility for creating, modifying and extracting from archives.
c++filt - Filter to demangle encoded C++ symbols.
dlltool - Creates files for building and using DLLs.
gold - A new, faster, ELF only linker, still in beta test.
gprof - Displays profiling information.
nlmconv - Converts object code into an NLM.
nm - Lists symbols from object files.
objcopy - Copies and translates object files.
objdump - Displays information from object files.
ranlib - Generates an index to the contents of an archive.
readelf - Displays information from any ELF format object file.
size - Lists the section sizes of an object or archive file.
strings - Lists printable strings from files.
strip - Discards symbols.
windmc - A Windows compatible message compiler.
windres - A compiler for Windows resource files.

0xdeadbabeOctober 25, 2014 7:20 PM
Oh shit,

It‘s not funny when you realize that that somebody is discovering priv8 0days.
I‘ve laughed a lot for a while targeting some white-hat biatches xDDDD. Here it
goes another one related with PE file headers parsing ^_^ , indeed, I could say
that there are tons of bugs related with binary parsing in binutils ]:-D

$ strings /tmp/prueba.exe
*** stack smashing detected ***: terminated
======= Backtrace: =========
/usr/lib/libc.so.6(+0x7340e)[0x7f81ad08340e]
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f81ad108a97]
/usr/lib/libc.so.6(__fortify_fail+0x0)[0x7f81ad108a60]
/usr/lib/libbfd-2.24.so(+0xb79a2)[0x7f81ad46f9a2]
======= Memory map: ========
00400000-00406000 r-xp 00000000 08:02 433688 /usr/bin/strings
00605000-00606000 r--p 00005000 08:02 433688 /usr/bin/strings
00606000-00607000 rw-p 00006000 08:02 433688 /usr/bin/strings
020f5000-02137000 rw-p 00000000 00:00 0 [heap]
[...]
7f81ad6b5000-7f81ad6c7000 r--p 000fd000 08:02 436332 /usr/lib/libbfd-2.24.so
7f81ad6c7000-7f81ad6cd000 rw-p 0010f000 08:02 436332 /usr/lib/libbfd-2.24.so
7fffc1e5a000-7fffc1e7c000 rw-p 00000000 00:00 0 [stack]
7fffc2000000-7fffc2002000 r-xp 00000000 00:00 0 [vdso]
7fffc2002000-7fffc2004000 r--p 00000000 00:00 0 [vvar]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Abortado (`core‘ generado)


Hey guys, do you wanna find something when fuzzing? Use as input the awesome
radare2 regression tests https://github.com/radare/radare2-regressions.

And for you Micha?, thanks for all you‘re work! Keep on it, maquina!

Viva Andalucia Libre!

solar  gentoo-dev 2005-05-04 02:29:08 UTC
Only the first 78 bytes of the a.out matter. (head -c78 a.out)

gdb crashes here.

#0  0x081dbe78 in bfd_elf32_object_p (abfd=0x831e458) at elfcode.h:662
#1  0x081c856c in bfd_check_format_matches (abfd=0x831e458, format=bfd_object, matching=0x0) at format.c:228
#2  0x081c8324 in bfd_check_format (abfd=0x831e458, format=bfd_object) at format.c:91
#3  0x08079fd0 in exec_file_attach (filename=0xbfffe615 "a.out", from_tty=0x1) at exec.c:221
#4  0x0807e390 in do_captured_command (data=0xbfffe120) at top.c:554
#5  0x0807e2fc in do_catch_errors (uiout=0x831cdc8, data=0xbfffe0f8) at top.c:524
#6  0x0807e0a0 in catcher (func=0x807e2e0 <do_catch_errors>, func_uiout=0x831cdc8, func_args=0xbfffe0f8, func_val=0xbfffe104, func_caught=0xbfffe100, errstring=0x823e4c1 "", gdberrmsg=0x0, mask=0x6) at top.c:431
#7  0x0807e350 in catch_errors (func=0x807e36a <do_captured_command>, func_args=0xbfffe120, errstring=0x823e4c1 "", mask=0x6) at top.c:536
#8  0x0807e3dd in catch_command_errors (command=0x8079eae <exec_file_attach>, arg=0xbfffe615 "a.out", from_tty=0x1, mask=0x6) at top.c:574
#9  0x0807536d in captured_main (data=0xbfffe440) at main.c:645
#10 0x0807e2fc in do_catch_errors (uiout=0x82c8c80, data=0xbfffe3f8) at top.c:524
#11 0x0807e0a0 in catcher (func=0x807e2e0 <do_catch_errors>, func_uiout=0x82c8c80, func_args=0xbfffe3f8, func_val=0xbfffe404, func_caught=0xbfffe400, errstring=0x823a71a "", gdberrmsg=0x0, mask=0x6) at top.c:431
#12 0x0807e350 in catch_errors (func=0x80748e7 <captured_main>, func_args=0xbfffe440, errstring=0x823a71a "", mask=0x6) at top.c:536
#13 0x08075702 in gdb_main (args=0xbfffe440) at main.c:810
#14 0x080748a4 in main (argc=0x2, argv=0xbfffe4b4) at gdb.c:35