Home Original page

vulnerabilities in libbfd (CVE-2014-beats-me)

Maciej W. Rozycki macro@linux-mips.org
Mon Oct 27 14:57:00 GMT 2014 
On Sun, 26 Oct 2014, Michal Zalewski wrote:

> Yo,
> 
> 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
> ...
> $ 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

 Has this issue been reported to binutils maintainers?

 I agree sanitising pointers calculated based on data taken from 
untrusted sources, including broken or deliberately corrupted 
executables, is a must.

  Maciej
More information about the Binutils mailing list