Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 May 2016 11:51:13 +0300
From: Solar Designer <solar@...nwall.com>
To: Yue Liu <liuyue0310@...il.com>
Cc: oss-security@...ts.openwall.com, David Anderson <davea42@...uxmail.org>
Subject: Re: CVE request: Multiple vunerabilities in libdwarf & dwarfdump

Hi,

On oss-security it is strongly preferred that actual content (rather
than just links) be included in the postings for long-term archival,
as long as the message doesn't exceed 200 KB (including MIME overhead).

On Tue, May 24, 2016 at 04:01:42PM +0800, Yue Liu wrote:
> There are multiple vunerabilities in libdwarf&dwarfdump which were
> discovered by Yue Liu(lieanu <liuyue0310@...il.com>) and Qixue Xiao.
> 
> Vulnerabilities DW201605-001 to DW201605-019 in
> https://www.prevanders.net/dwarfbug.html

I've attached the current content of the above web page to this message,
as text/plain.

> And anther one https://bugzilla.redhat.com/show_bug.cgi?id=1330237

Here it is:

---
Description of problem:
There is a NULL pointer dereference bug in libdwarf-20160115 and latest git code.

The bug is at file dwarf_leb.c:147
 143             byte_length++;
 144             if (byte_length > BYTESLEBMAX) {
 145                 /*  Erroneous input. What to do?
 146                     Abort? Return error? Just stop here?*/
 147                 *leb128_length = BYTESLEBMAX;               <- $pc
 148                 return number;
 149             }
 150         }

which triggered by dwarf_form.c:918
 913             *return_sval = (Dwarf_Signed) ret_value;
 914             return DW_DLV_OK;
 915             }
 916
 917         case DW_FORM_sdata:
 918             ret_value =
 919                 (_dwarf_decode_s_leb128(attr->ar_debug_ptr, NULL));
 920             *return_sval = ret_value;
 921             return DW_DLV_OK;
 922

Version-Release number of selected component (if applicable):
Tested in libdwarf-20160115 and latest git code
---

> All vulnerabilities have been fixed in upstream.
> 
> POC: https://sourceforge.net/p/libdwarf/regressiontests/ci/master/tree/liu/

Unfortunately, some of the PoCs are a bit too large to attach.  While
the above directory is ~110 KB under tar.xz, the PoC attached to Red Hat
Bugzilla Bug 1330237 is ~150 KB under xz.

So let's keep just the vulnerability detail in here for now.

One of the reasons why I am posting this is to provide an example of
what content to include in oss-security postings going forward.  Also,
it's a call for smaller PoCs (for further occasions; no need to rework
these PoCs now), so that those could be included as well.

Alexander

                            David A's DWARF Page

                                Introduction

 This page provides documentation of known vulnerabilities in libdwarf. We
 are concerned here with cases where corrupt (by accident or intention)
 DWARF can cause the library to get a fault (crash) which could expose the
 calling program to interception by malefactors. The page is new as of 4
 May, 2016 (20160504 as an ISO date) and its content may change radically
 as we determine what this page should contain and whether this page is a
 good idea.

 For an xml version of the same data one should refer to
 https://www.prevanders.net/dwarfbug.xml

 Git commit string ids refer to the source on sourceforge.net. The source
 can be retrieved via anonymous access:
 "git clone git://git.code.sf.net/p/libdwarf/code"

 Git reference path names refer to object files in the libdwarf regression
 test base. The test files can be retrieved via anonymous access:
 "git clone git://git.code.sf.net/p/libdwarf/regressiontests" .

                              Vulnerabilities

 Vulnerabilities are listed newest-first.

DW201605-019

 id: DW201605-019

 cve:

 datereported: 20160523

 reportedby: Yue Liu

 vulnerability: Null derefernce in print_frame_inst_bytes (dwarfdump)

 product: libdwarf

 description: The null dereference is due to a corrupted object file.
 Libdwarf was not dealing with empty (bss-like) sections since it really
 did not expect to see such in sections it reads! Now libdwarf catches the
 object error so dwarfdump sees the section as empty (as indeed it is!).

 datefixed: 20160523

 references: dwarftests/liu/NULLdeference0522c.elf

 gitfixid: a55b958926cc67f89a512ed30bb5a22b0adb10f4

 tarrelease:


DW201605-018

 id: DW201605-018

 cve:

 datereported: 20160522

 reportedby: Yue Liu

 vulnerability: Null dereference in create_fullest_file_path().

 product: libdwarf

 description: The null dereference in create_fullest_file_path() causes a
 crash. This is due to corrupted dwarf and the fix detects this corruption
 and if that null string pointer happens undetected a static string is
 substituted so readers can notice the situation.

 202             }
203             if (dirno > 0 && fe->fi_dir_index > 0) {
204                 inc_dir_name = (char *)
                        line_context->lc_include_directories[
205                     fe->fi_dir_index - 1];
206                 incdirnamelen = strlen(inc_dir_name);  <- $pc
207             }
208             full_name = (char *) _dwarf_get_alloc(dbg,
#0  create_fullest_file_path (dbg=<optimized out>,
fe=0x68d510, line_context=0x68c4f0, name_ptr_out=<optimized
out>, error=0x7fffffffe2b8) at ./dwarf_line.c:206
#1  0x00007ffff7b6d3f9 in dwarf_filename (context=<optimized
out>, fileno_in=<optimized out>, ret_filename=0x7fffffffe280,
error=0x7fffffffe2b8) at ./dwarf_line.c:1418
#2  dwarf_linesrc (line=<optimized out>,
ret_linesrc=<optimized out>, error=<optimized out>) at
./dwarf_line.c:1436


 datefixed: 20160522

 references: dwarftests/liu/NULLdereference0522.elf

 gitfixid: acae971371daa23a19358bc62204007d258fbc5e

 tarrelease:


DW201605-017

 id: DW201605-017

 cve:

 datereported: 20160519

 reportedby: Yue Liu

 vulnerability: Null dereference bug in
 _dwarf_calculate_info_section_end_ptr().

 product: libdwarfj

 description: NULL dereference bug in
 _dwarf_calculate_info_section_end_ptr().

1742         Dwarf_Off off2 = 0;
1743         Dwarf_Small *dataptr = 0;
1744
1745         dbg = context->cc_dbg;
1746         dataptr = context->cc_is_info? dbg->de_debug_info.dss_data:                 <- $pc
1747             dbg->de_debug_types.dss_data;
1748         off2 = context->cc_debug_offset;
1749         info_start = dataptr + off2;
1750         info_end = info_start + context->cc_length +
#0  _dwarf_calculate_info_section_end_ptr
(context=context@...ry=0x0) at dwarf_query.c:1746
#1  0x00002aaaaace307d in
_dwarf_extract_string_offset_via_str_offsets
(dbg=dbg@...ry=0x655a70, info_data_ptr=0x6629f0
"", attrnum=attrnum@...ry=121,
attrform=attrform@...ry=26, cu_context=0x0,
str_sect_offset_out=str_sect_offset_out@...ry=0x7fffffffd718,
error=error@...ry=0x7fffffffd878) at dwarf_form.c:1099
#2  0x00002aaaaacf4ed7 in dwarf_get_macro_defundef
(macro_context=macro_context@...ry=0x65b790,
op_number=op_number@...ry=1,
line_number=line_number@...ry=0x7fffffffd858,
index=index@...ry=0x7fffffffd860,
offset=offset@...ry=0x7fffffffd868,
forms_count=forms_count@...ry=0x7fffffffd7ce,
macro_string=macro_string@...ry=0x7fffffffd870,
error=error@...ry=0x7fffffffd878) at dwarf_macro5.c:557
------
_dwarf_calculate_info_section_end_ptr (context=context@...ry=0x0) at
  dwarf_query.c:1746
1746        dataptr = context->cc_is_info? dbg->de_debug_info.dss_data:
gef> p/x $rdi
$4 = 0x0


 datefixed: 20160522

 references: regressiontests/liu/NULLdereference0519.elf

 gitfixid: 6fa3f710ee6f21bba7966b963033a91d77c952bd

 tarrelease:


DW201605-016

 id: DW201605-016

 cve:

 datereported: 20160519

 reportedby: Yue Liu

 vulnerability: Invalid dwarf leads to dwarfdump crash in
 print_frame_inst_bytes.

 product: dwarfdump

 description: Corrupted dwarf crashes dwarfdump

1297         }
1298         len = len_in;
1299         endpoint = instp + len;
1300         for (; len > 0;) {
1301             unsigned char ibyte = *instp;           <- $pc
1302             int top = ibyte & 0xc0;
1303             int bottom = ibyte & 0x3f;
1304             int delta = 0;
1305             int reg = 0;
#0  print_frame_inst_bytes (dbg=dbg@...ry=0x655ca0,
cie_init_inst=<optimized out>, len_in=<optimized out>,
data_alignment_factor=-4, code_alignment_factor=4,
addr_size=addr_size@...ry=4, offset_size=4, version=3,
config_data=config_data@...ry=0x63cda0 <g_config_file_data>)
at print_frames.c:1301
#1  0x000000000041b70c in print_one_cie
(dbg=dbg@...ry=0x655ca0, cie=<optimized out>,
cie_index=cie_index@...ry=2, address_size=<optimized out>,
config_data=config_data@...ry=0x63cda0 <g_config_file_data>)
at print_frames.c:1161
#2  0x000000000041cf52 in print_frames (dbg=0x655ca0,
print_debug_frame=print_debug_frame@...ry=1, print_eh_frame=0,
config_data=config_data@...ry=0x63cda0 <g_config_file_data>)
at print_frames.c:2229
gef> p/x $r13
$1 = 0x4bcad8
gef> p/x *$r13
Cannot access memory at address 0x4bcad8


 datefixed: 20160522

 references: regressiontests/liu/OOB_READ0519.elf

 gitfixid: 6fa3f710ee6f21bba7966b963033a91d77c952bd

 tarrelease:


DW201605-015

 id: DW201605-015

 cve:

 datereported: 20160517

 reportedby: Yue Liu

 vulnerability: OOB read bug in print_frame_inst_bytes()

 product: libdwarf

 description: Test object shows an invalid read in
 print_frame_inst_bytes().

1294         for (; len > 0;) {
1295             unsigned char ibyte = *instp;           <- $pc
1296             int top = ibyte & 0xc0;
#0  print_frame_inst_bytes (dbg=dbg@...ry=0x654c80,
   cie_init_inst=<optimized out>, len=503715, data_alignment_factor=-4,
   code_alignment_factor=1, addr_size=addr_size@...ry=4, offset_size=4,
   version=3, config_data=config_data@...ry=0x63bda0
   <g_config_file_data>) at print_frames.c:1295
#1  0x000000000041b64c in print_one_cie (dbg=dbg@...ry=0x654c80,
   cie=<optimized out>, cie_index=cie_index@...ry=1,
   address_size=<optimized out>, config_data=
   config_data@...ry=0x63bda0 <g_config_file_data>) at print_frames.c:1161
#2  0x000000000041ce92 in print_frames (dbg=0x654c80,
   print_debug_frame=print_debug_frame@...ry=1, print_eh_frame=0,
   config_data=config_data@...ry=0x63bda0 <g_config_file_data>)
   at print_frames.c:2209
gef> x/10x $r13
0x5e7981:       Cannot access memory at address 0x5e7981
gef> p/x $r13
$14 = 0x5e7981


 datefixed: 20150518

 references: regressiontests/liu/OOB0517_03.elf

 gitfixid: ac6673e32f3443a5d36c2217cb814000930b2c54

 tarrelease:


DW201605-014

 id: DW201605-014

 cve:

 datereported: 20160517

 reportedby: Yue Liu

 vulnerability: OOB read bug in dwarf_get_xu_hash_entry()

 product: libdwarf

 description: Test object shows an invalid read in dwarf_get
 _xu_hash_entry, lin 211.

#0  dwarf_get_xu_hash_entry (xuhdr=xuhdr@...ry=0x657360,
   index=index@...ry=2897626028, hash_value=
   hash_value@...ry=0x7fffffffd5b0,
   index_to_sections=index_to_sections@...ry=0x7fffffffd5a8,
   err=err@...ry=0x7fffffffdb08) at dwarf_xu_index.c:211
#1  0x00002aaaaacfd05e in _dwarf_search_fission_for_key (
   dbg=0x654a50, error=0x7fffffffdb08, percu_index_out=<synthetic pointer>,
   key_in=0x7fffffffd670, xuhdr=0x657360) at dwarf_xu_index.c:363
#2  dwarf_get_debugfission_for_key (dbg=dbg@...ry=0x654a50,
   key=key@...ry=0x7fffffffd670, key_type=key_type@...ry=0x2aaaaad15e2a
   "tu", percu_out=percu_out@...ry=0x65a830,
   error=error@...ry=0x7fffffffdb08) at dwarf_xu_index.c:577


 datefixed: 20150518

 references: regressiontests/liu/OOB0517_02.elf

 gitfixid: ac6673e32f3443a5d36c2217cb814000930b2c54

 tarrelease:


DW201605-013

 id: DW201605-013

 cve:

 datereported: 20160517

 reportedby: Yue Liu

 vulnerability: OOB read bug in print_exprloc_content

 product: libdwarf

 description: Test object shows an invalid write in print_exprloc_content.

#0  print_exprloc_content (dbg=dbg@...ry=0x654ea0,
   die=die@...ry=0x65b110, attrib=attrib@...ry=0x65b590,
   esbp=esbp@...ry=0x7fffffffcef0, showhextoo=1) at print_die.c:4182
#1  0x0000000000412fb1 in get_attr_value (dbg=dbg@...ry=0x654ea0,
   tag=<optimized out>, die=die@...ry=0x65b110,
   dieprint_cu_goffset=dieprint_cu_goffset@...ry=11,
   attrib=attrib@...ry=0x65b590, srcfiles=srcfiles@...ry=0x0,
   cnt=cnt@...ry=0, esbp=esbp@...ry=0x7fffffffcef0, show_form=0,
   local_verbose=0) at print_die.c:4972


 datefixed: 20150518

 references: regressiontests/liu/OOB0517_01.elf

 gitfixid: ac6673e32f3443a5d36c2217cb814000930b2c54

 tarrelease:


DW201605-012

 id: DW201605-012

 cve:

 datereported: 20160513

 reportedby: Yue Liu

 vulnerability: OOB write. From relocation records

 product: libdwarf

 description: Test object shows an invalid write in dwarf_elf_access.c
 (when doing the relocations). Adding the relocation value to anything
 overflowed and disguised the bad relocation record. With a 32bit kernel
 build the test could show a double-free and coredump due to the unchecked
 invalid writes from relocations.

 datefixed: 20160517

 references: regressiontests/liu/HeapOverflow0513.elf

 gitfixid: 10ca310f64368dc083efacac87732c02ef560a92

 tarrelease:


DW201605-011

 id: DW201605-011

 cve:

 datereported: 20160506

 reportedby: Yue Liu

 vulnerability: OOB read bug in _dwarf_read_line_table_header

 product: libdwarf

 description: Test object shows null dereference at line 62 of
 dwarf_line_table_reader.c. Frame code and linetable code was not noticing
 data corruption.

 datefixed: 20160512

 references: regressiontests/liu/OOB_read4.elf

 gitfixid: 82d8e007851805af0dcaaff41f49a2d48473334b

 tarrelease:


DW201605-010

 id: DW201605-010

 cve:

 datereported: 20160506

 reportedby: Yue Liu

 vulnerability: OOB read bug in dump_block

 product: libdwarf

 description: Test object shows null dereverence at line 186 of
 dump_block() in print_sections.c Frame code was not noticing frame data
 corruption.

 datefixed: 20160512

 references: regressiontests/liu/OOB_read3.elf
 regressiontests/liu/OOB_read3_02.elf

 gitfixid: 82d8e007851805af0dcaaff41f49a2d48473334b

 tarrelease:


DW201605-009

 id: DW201605-009

 cve:

 datereported: 20160505

 reportedby: Yue Liu

 vulnerability: NULL dereference in _dwarf_load_section

 product: libdwarf

 description: Test object shows null dereverence at line 1010
 if(!strncmp("ZLIB",(const char *)src,4)) { in dwarf_init_finish.c The zlib
 code was not checking for a corrupted length-value.

 datefixed: 20160506

 references: regressiontests/liu/NULLderefer0505_01.elf

 gitfixid: b6ec2dfd850929821626ea63fb0a752076a3c08a

 tarrelease: 20160507


DW201605-008

 id: DW201605-008

 cve:

 datereported: 20160505

 reportedby: Yue Liu

 vulnerability: OOB read in dwarf_get_macro_startend_file()

 product: libdwarf

 description: Test object shows out of bound read. OOB at: line 772
 *src_file_name = macro_context->mc_srcfiles[trueindex]; in dwarf_macro5.c
 A string offset into .debug_str is outside the bounds of the .debug_str
 section.

 datefixed: 20160512

 references: regressiontests/liu/OOB0505_02.elf
 regressiontests/liu/OOB0505_02_02.elf

 gitfixid: 82d8e007851805af0dcaaff41f49a2d48473334b

 tarrelease:


DW201605-007

 id: DW201605-007

 cve:

 datereported: 20160505

 reportedby: Yue Liu

 vulnerability: OOB read bug in get_attr_value()

 product: libdwarf

 description: Test object shows out of bound read. Object had data
 all-bits-on so the existing length check did not work due to wraparound.
 Added a check not susceptible to that error
 (DW_DLE_FORM_BLOCK_LENGTH_ERROR).

 datefixed: 20160506

 references: regressiontests/liu/OOB0505_01.elf

 gitfixid: eb1472afac95031d0c9dd8c11d527b865fe7deb8

 tarrelease: 20160507


DW201605-006

 id: DW201605-006

 cve:

 datereported: 20160505

 reportedby: Yue Liu

 vulnerability: Two Heap-Overflow bug

 product: libdwarf

 description: Two test objects showing a heap overflow in libdwarf when
 using dwarfdump. It seems that these were fixed by the previous git
 update. Neither gdb nor valgrind find any errors when building with
 yesterday's commit.

 datefixed: 20160504

 references: regressiontests/liu/free_invalid_address.elf
 regressiontests/liu/heapoverflow01b.elf

 gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f

 tarrelease: 20160507


DW201605-005

 id: DW201605-005

 cve:

 datereported: 20160502

 reportedby: Yue Liu

 vulnerability: A specially crafted DWARF section results in reading a
 compilation unit header that crashes the application.

 product: libdwarf

 description: If the data read for a compilation unit header contains a too
 large length value the library will read outside of its bounds and crash
 the application.

 datefixed: 20160504

 references: regressiontests/liu/null02.elf

 gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f

 tarrelease: 20160507


DW201605-004

 id: DW201605-004

 cve:

 datereported: 20160502

 reportedby: Yue Liu

 vulnerability: A specially crafted DWARF section results in a null
 dereference reading debugging information entries which crashes the
 application.

 product: libdwarf

 description: If no DW_AT_name is present in a debugging information entry
 using DWARF5 macros a null dereference in dwarf_macro5.c will crash the
 application.

 datefixed: 20160504

 references: regressiontests/liu/null01.elf

 gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f

 tarrelease: 20160507


DW201605-003

 id: DW201605-003

 cve:

 datereported: 20160502

 reportedby: Yue Liu

 vulnerability: A specially crafted DWARF section results in an infinite
 loop that eventually crashes the application.

 product: libdwarf

 description: In dwarf_get_aranges_list() an invalid count will iterate,
 reading from memory addresses that increase till it all fails.

 datefixed: 20160504

 references: regressiontests/liu/infiniteloop.elf

 gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f

 tarrelease: 20160507


DW201605-002

 id: DW201605-002

 cve:

 datereported: 20160502

 reportedby: Yue Liu

 vulnerability: A specially crafted DWARF section results in a read outside
 the bounds of in memory data so the calling application can crash.

 product: libdwarf

 description: Out of bound read bug in libdwarf git code. dwarf_dealloc()
 did not check the Dwarf_Ptr space argument before using it. This will lead
 to a out-of-bound read bug.

backtrace:
#0  dwarf_dealloc (dbg=dbg@...ry=0x655f30, space=0xa0,
alloc_type=alloc_type@...ry=1) at dwarf_alloc.c:477
#1  0x00002aaaaacf3296 in dealloc_srcfiles
(dbg=0x655f30, srcfiles=0x66b8f0, srcfiles_count=17) at
dwarf_macro5.c:1025 #2  0x00002aaaaacf50e6 in dealloc_srcfiles
(srcfiles_count=<optimized out>, srcfiles=<optimized out>,
dbg=<optimized out>) at dwarf_macro5.c:1021 -----
gef> p &r->rd_dbg
$14 = (void **) 0x90


 datefixed: 20160504

 references: regressiontests/liu/outofbound01.elf

 gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f

 tarrelease: 20160507


DW201605-001

 id: DW201605-001

 cve:

 datereported: 20160502

 reportedby: Yue Liu

 vulnerability: A specially crafted DWARF section results in a duplicate
 free() in libdwarf and the calling application will crash.

 product: libdwarf

 description: In file dwarf_elf_access.c:1071

WRITE_UNALIGNED(dbg,target_section + offset,
    &outval,sizeof(outval),reloc_size);


 A crafted ELF file may lead to a large offset value, which bigger than the
 size of target_section heap chunk, then this WRITE_UNALIGNED() function
 will write the value of &outval out of the heap chunk. offset is a 64bit
 unsigned int value, so this is more than a heap overflow bug, but also a
 Out-of-Bound write bug. So WRITE_UNALIGNED() need more strictly checking
 to prevent this.

 datefixed: 20160504

 references: regressiontests/liu/heapoverflow01.elf

 gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f

 tarrelease: 20160507

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ