This is the mail archive of the
mailing list for the binutils project.
Re: vulnerabilities in libbfd (CVE-2014-beats-me)
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Michal Zalewski <lcamtuf at coredump dot cx>
- Cc: bugtraq <bugtraq at securityfocus dot com>, binutils at sourceware dot org
- Date: Mon, 27 Oct 2014 14:57:12 +0000 (GMT)
- Subject: Re: vulnerabilities in libbfd (CVE-2014-beats-me)
- Authentication-results: sourceware.org; auth=none
- References: <CALx_OUBq4iRGZNPLdCuqXmehVV=6vhXN3J16ytzM91cFqVSAoQ at mail dot gmail dot com>
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?
I agree sanitising pointers calculated based on data taken from
untrusted sources, including broken or deliberately corrupted
executables, is a must.