Back to list
Re: vulnerabilities in libbfd (CVE-2014-beats-me)
Oct 27 2014 05:18PM
Mike Frysinger (vapier gentoo 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  (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: 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
> 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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
[ reply ]
Copyright 2010, SecurityFocus