|
Message-ID: <20141023121232.4ac7017b@pc>
Date: Thu, 23 Oct 2014 12:12:32 +0200
From: Hanno Böck <hanno@...eck.de>
To: oss-security@...ts.openwall.com
Subject: strings / libbfd crasher
Hi,
I'm forwarding this here so it doesn't get lost:
https://twitter.com/lcamtuf/status/524213424373243905
https://twitter.com/lcamtuf/status/524214698237898753
http://lcamtuf.coredump.cx/stringme
Short: Michal Zalewski (who is also on this list and probably can give
us some more info) fuzzed a sample that crashes the strings command,
due to a bug in libbfd.
(by the way: nice catch, always interesting to see potential vulns in
places you don't expect them.)
strings/libbfd belong to binutils.
I haven't seen a corresponding commit, their latest release is a bit
old.
I think it deserves a CVE and further analysis. Seems to be "only" an
out of bounds read.
Some valgrind output that gives an idea whats going on:
==6858== Memcheck, a memory error detector
==6858== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6858== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==6858== Command: strings stringme
==6858==
==6858== Invalid read of size 1
==6858== at 0x4E8708F: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858== Address 0x590beb6 is 0 bytes after a block of size 6 alloc'd
==6858== at 0x4C28F60: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6858== by 0x4E7C92D: bfd_malloc (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E86CEA: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858==
==6858== Invalid read of size 1
==6858== at 0x4E8709E: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858== Address 0x590beb7 is 1 bytes after a block of size 6 alloc'd
==6858== at 0x4C28F60: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6858== by 0x4E7C92D: bfd_malloc (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E86CEA: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858==
==6858== Invalid read of size 1
==6858== at 0x4E87200: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858== Address 0x590beb8 is 2 bytes after a block of size 6 alloc'd
==6858== at 0x4C28F60: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6858== by 0x4E7C92D: bfd_malloc (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E86CEA: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858==
==6858== Invalid read of size 1
==6858== at 0x4E87207: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858== Address 0x590beb9 is 3 bytes after a block of size 6 alloc'd
==6858== at 0x4C28F60: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6858== by 0x4E7C92D: bfd_malloc (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E86CEA: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858==
==6858==
==6858== Process terminating with default action of signal 11 (SIGSEGV)
==6858== Access not within mapped region at address 0x60B4000
==6858== at 0x4E87200: srec_scan (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E87529: srec_object_p (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x4E7C00C: bfd_check_format_matches (in /usr/lib64/binutils/x86_64-pc-linux-gnu/2.24/libbfd-2.24.so)
==6858== by 0x401F45: main (in /usr/x86_64-pc-linux-gnu/binutils-bin/2.24/strings)
==6858== If you believe this happened as a result of a stack
==6858== overflow in your program's main thread (unlikely but
==6858== possible), you can try to increase the size of the
==6858== main thread stack using the --main-stacksize= flag.
==6858== The main thread stack size used in this run was 8388608.
==6858==
==6858== HEAP SUMMARY:
==6858== in use at exit: 9,046 bytes in 7 blocks
==6858== total heap usage: 41 allocs, 34 frees, 13,216 bytes allocated
==6858==
==6858== LEAK SUMMARY:
==6858== definitely lost: 0 bytes in 0 blocks
==6858== indirectly lost: 0 bytes in 0 blocks
==6858== possibly lost: 0 bytes in 0 blocks
==6858== still reachable: 9,046 bytes in 7 blocks
==6858== suppressed: 0 bytes in 0 blocks
==6858== Rerun with --leak-check=full to see details of leaked memory
==6858==
==6858== For counts of detected and suppressed errors, rerun with: -v
==6858== ERROR SUMMARY: 4178251 errors from 4 contexts (suppressed: 0
from 0)
--
Hanno Böck
http://hboeck.de/
mail/jabber: hanno@...eck.de
GPG: BBB51E42
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.