strings / libbfd (Chromium 37.0.2062.120) out of bounds read

2014-10-23 / 2014-10-24
Risk: High
Local: Yes
Remote: No
CVE: N/A
CWE: N/A

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 Bock http://hboeck.de/

References:

http://seclists.org/oss-sec/2014/q4/424
http://seclists.org/oss-sec/2014/q4/426


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top