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 [1] (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

Exploit-DB Mirror: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/35081.bin

...
$ 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)
          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 [2].

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 [3].

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.

[1] Obligatory plug: http://code.google.com/p/american-fuzzy-lop/
[2] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html
[3] https://bugs.gentoo.org/show_bug.cgi?id=91398