Bug 24131 - A unsigned integer overflow found in readelf which may cause OOB memory access
Summary: A unsigned integer overflow found in readelf which may cause OOB memory access
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.31
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-24 18:40 UTC by poppeter1982
Modified: 2019-01-25 18:24 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
The PoC to demonstrate the unsigned integer overflow (21.13 KB, application/x-core)
2019-01-24 18:40 UTC, poppeter1982
Details
attachment-36335-0.html (792 bytes, text/html)
2019-01-25 18:24 UTC, poppeter1982
Details

Note You need to log in before you can comment on or make changes to this bug.
Description poppeter1982 2019-01-24 18:40:59 UTC
Created attachment 11568 [details]
The PoC to demonstrate the unsigned integer overflow

Hi There
 
Peng Li and Shengjian Guo at Baidu XLab discovered a suspicious unsigned integer overflow which may lead to out of bound access. The bug is found in function process_notes_at of readelf.c of version 2.31.51.20190117.
 
static bfd_boolean
process_notes_at (Filedata *           filedata,
                  Elf_Internal_Shdr *  section,
                  bfd_vma              offset,
                  bfd_vma              length,
                  bfd_vma              align)
{
       …
       if (inote.namedata[inote.namesz - 1] != '\0') {
….
       }
}
 
If you compile readelf with -fsanitize=unsigned-integer-overflow and run ./readelf -a input, it is found that inote.namesz is equal to 0, “inote.namesz – 1” wraps around and becomes a super large number, causing the out of bound access. Can you please help verify if it is a true positive?
 
If you have any questions about this issue and input in the attachment, please let me know.
 
 
Thanks
Peng
Comment 1 cvs-commit@gcc.gnu.org 2019-01-25 13:17:33 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=183445093ebd6be285e29f75b877e62a723918c6

commit 183445093ebd6be285e29f75b877e62a723918c6
Author: Nick Clifton <nickc@redhat.com>
Date:   Fri Jan 25 13:16:06 2019 +0000

    Prevent a potential illegal memory access in readelf when parsing a note with a zero name size.
    
    	PR 24131
    	* readelf.c (process_notes_at): Prevent an illegal memory access
    	when the note's namesize is zero.
    	(decode_tic6x_unwind_bytecode): Add code to handle the case where
    	no registers are specified in a frame pop instruction.
Comment 2 Nick Clifton 2019-01-25 14:06:00 UTC
Hi Peng,

  Thanks for reporting this problem.  I agree that this is a potential
  illegal memory access here, so I have checked in the obvious patch to
  fix the problem.

  Whilst I was inspecting the readelf sources I also found a similar
  potential vulnerability, so I included a fix for that in the patch
  as well.

Cheers
  Nick
Comment 3 poppeter1982 2019-01-25 18:24:24 UTC
Created attachment 11570 [details]
attachment-36335-0.html

Hi Nick

Thank you for confirming and fixing this issue promptly.

Best,
Peng

nickc at redhat dot com <sourceware-bugzilla@sourceware.org> 于2019年1月25日周五
上午6:06写道:

> https://sourceware.org/bugzilla/show_bug.cgi?id=24131
>
> Nick Clifton <nickc at redhat dot com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>                  CC|                            |nickc at redhat dot com
>          Resolution|---                         |FIXED
>
> --- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
> Hi Peng,
>
>   Thanks for reporting this problem.  I agree that this is a potential
>   illegal memory access here, so I have checked in the obvious patch to
>   fix the problem.
>
>   Whilst I was inspecting the readelf sources I also found a similar
>   potential vulnerability, so I included a fix for that in the patch
>   as well.
>
> Cheers
>   Nick
>
> --
> You are receiving this mail because:
> You reported the bug.