BugTraq
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 [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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUTn5wAAoJEEFjO5/oN/WBeLgQALQcg9hmQq2V1YHyvd0AMhQW
khitYKeVNZPszOywJT2kMwLBmrmDm6TH2fVhpwQq4KfQe3iZ5O1mlRbYVnneYUhp
Uy3865NmITxZKOJghGxFZiLGreTDHEFoyfIBkL0YOJ2F3AmFnBfl/+RrhAO7D1qD
UWod8LZwKro1R9ZuYEbvyq9+9LGz0X/1M0M3SS0VI73LweQiinSsA8oBzd2wQEhw
+glycRdvwKdu2JNy200V5hlgst5FBcHYqMFMB4hFp4ck8HEzPDmw4mWY1V+S7qKv
BHmOWy+K7JD4stWWHbEe9QIcErbI/07sm7c0eEt/dGW9T0s7uIvSbDtsrbBhh1gA
Imv4vBPyiXsEASULeKYgk9V2U0KxTvSRl5Zfy9w5GZT2jrXbBFs5T3SPm6VVcekl
ckP/v55N8HCbI7b1/i//uUm5TQDi8QpodUdje/eSn9mxPdN9wtlwurYkd0+WIjaL
67eRAq4O99RHzGZedcY1TPHwJ8ANSAvQyFwVYxlCCGB5jGvQ9pNm8zbj6jZ1y8sa
gLMViyLStATBs2tca79q7DfBG5VEMMZjRnbdPOHGeTE8OvdzZjsTygQKwa4VI1XW
xZxdr/is63f1+LIoZS+lubWCAkUDfmdlM99F/nt8cjM02E7Drl+piCBQnX1ixaxz
L8awnL9D1r2F6qgVIgRM
=u2Ws
-----END PGP SIGNATURE-----

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus