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

[Mike Frysinger <vapier at gentoo dot org>]

On 27 Oct 2014 14:57, Maciej W. Rozycki wrote:
> On Sun, 26 Oct 2014, Michal Zalewski wrote:
> > 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?

a few have been reported recently, but not sure if this is the same one.  best 
to file a bug on sourceware.org/bugzilla/ and as people walk through the 
reports, collapse as needed.

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

sure, but honestly, invoking bfd in any sort of security sensitive context is a 
terrible terrible idea.  it's full of range issues like this (by nature of its 
job), and will continue to be so.  unless we switch to a language like python 
where exceeding memory ranges is guaranteed to not access invalid memory (not 
that i'm suggesting that).
-mike

Attachment: signature.asc
Description: Digital signature