Bug 21300

Summary: heap-based buffer overflow in ebl_object_note_type_name (eblobjnotetypename.c)
Product: elfutils Reporter: Agostino Sarubbo <ago>
Component: toolsAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: elfutils-devel, mark
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: stacktrace

Description Agostino Sarubbo 2017-03-24 09:16:14 UTC
Created attachment 9937 [details]
stacktrace

On elfutils-0.168:

# eu-readelf -a $FILE
READ of size 1 at 0x60200000ef9c thread T0
    #1 0x4f63a7 in ebl_object_note_type_name /tmp/portage/dev-libs/elfutils-0.168/work/elfutils-0.168/libebl/eblobjnotetypename.c:48

Compiled with: gcc-6.3.0

Reproducer:
https://github.com/asarubbo/poc/blob/master/00226-elfutils-heapoverflow-ebl_object_note_type_name

Stacktrace attached.
Comment 1 Mark Wielaard 2017-03-24 13:00:43 UTC
Nice find. The issue is with notes that have a zero sized name (and also no descriptor data at the end of a note section).

"The system reserves note information with no name (namesz==0) and with a zero-length name (name[0]=='\0') but currently defines no types. All other names must have at least one non-null character."

So we must explicitly check for namesz == 0 before using the name data in the note.
Comment 2 Mark Wielaard 2017-03-24 13:11:17 UTC
Posted a patch:
https://sourceware.org/ml/elfutils-devel/2017-q1/msg00111.html
Comment 3 Mark Wielaard 2017-04-03 21:51:18 UTC
commit b0b58c5e0b34e54194aa042f2310af58ee7de603
Author: Mark Wielaard <mark@klomp.org>
Date:   Fri Mar 24 14:10:26 2017 +0100

    Use the empty string for note names with zero size (without any data).
    
    ELF notes can have a zero sized name. In which case there is no data at
    all (so also no zero terminator). Make sure to use the empty string for
    such notes if the code does not otherwise explicitly check n_namesz.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=21300
    
    Signed-off-by: Mark Wielaard <mark@klomp.org>
Comment 4 Agostino Sarubbo 2017-04-10 07:28:44 UTC
Mitre assigned CVE-2017-7608 to this issue.