Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

stack-buffer-overflow in function calculate_gain(libfaad/sbr_hfadj.c:1287) #19

Closed
fantasy7082 opened this issue Dec 17, 2018 · 1 comment
Closed

stack-buffer-overflow in function calculate_gain(libfaad/sbr_hfadj.c:1287) #19

fantasy7082 opened this issue Dec 17, 2018 · 1 comment

Comments

@fantasy7082
Copy link

Hi, i found a stack-buffer-overflow bug in Freeware Advanced Audio Decoder 2 (FAAD2) 2.8.8, the details are below(ASAN):

./faad faad_res/013-stack-buffer-overflow-sbr_hfadj_1287 -o out.wav
 *********** Ahead Software MPEG-4 AAC Decoder V2.8.8 ******************

 Build: Dec 13 2018
 Copyright 2002-2004: Ahead Software AG
 http://www.audiocoding.com
 bug tracking: https://sourceforge.net/p/faac/bugs/
 Floating point version

 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License.

 **************************************************************************

faad_res/013-stack-buffer-overflow-sbr_hfadj_1287 file info:
RAW

=================================================================
==7025==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc1ba22024 at pc 0x7ffabd7b4a49 bp 0x7ffc1ba21cd0 sp 0x7ffc1ba21cc0
WRITE of size 4 at 0x7ffc1ba22024 thread T0
    #0 0x7ffabd7b4a48 in calculate_gain /root/faad2_asan/libfaad/sbr_hfadj.c:1287
    #1 0x7ffabd7b2392 in hf_adjustment /root/faad2_asan/libfaad/sbr_hfadj.c:83
    #2 0x7ffabd7d0725 in sbr_process_channel /root/faad2_asan/libfaad/sbr_dec.c:363
    #3 0x7ffabd7d17ea in sbrDecodeCoupleFrame /root/faad2_asan/libfaad/sbr_dec.c:479
    #4 0x7ffabd77e11b in reconstruct_channel_pair /root/faad2_asan/libfaad/specrec.c:1314
    #5 0x7ffabd783823 in channel_pair_element /root/faad2_asan/libfaad/syntax.c:759
    #6 0x7ffabd781cbf in decode_cpe /root/faad2_asan/libfaad/syntax.c:402
    #7 0x7ffabd782398 in raw_data_block /root/faad2_asan/libfaad/syntax.c:448
    #8 0x7ffabd73c9c3 in aac_frame_decode /root/faad2_asan/libfaad/decoder.c:990
    #9 0x7ffabd73c566 in NeAACDecDecode /root/faad2_asan/libfaad/decoder.c:821
    #10 0x40f8ae in decodeAACfile /root/faad2_asan/frontend/main.c:679
    #11 0x411dd4 in faad_main /root/faad2_asan/frontend/main.c:1323
    #12 0x411fe5 in main /root/faad2_asan/frontend/main.c:1366
    #13 0x7ffabd37482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #14 0x401aa8 in _start (/usr/local/faad-asan/bin/faad+0x401aa8)

Address 0x7ffc1ba22024 is located in stack of thread T0 at offset 740 in frame
    #0 0x7ffabd7b37a7 in calculate_gain /root/faad2_asan/libfaad/sbr_hfadj.c:1155

  This frame has 3 object(s):
    [32, 228) 'Q_M_lim'
    [288, 484) 'G_lim'
    [544, 740) 'S_M' <== Memory access at offset 740 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /root/faad2_asan/libfaad/sbr_hfadj.c:1287 calculate_gain
Shadow bytes around the buggy address:
  0x10000373c3b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000373c3c0: 00 00 00 00 04 f4 f4 f4 f2 f2 f2 f2 00 00 00 00
  0x10000373c3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000373c3e0: 00 00 00 00 04 f4 f4 f4 f2 f2 f2 f2 00 00 00 00
  0x10000373c3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10000373c400: 00 00 00 00[04]f4 f4 f4 f3 f3 f3 f3 00 00 00 00
  0x10000373c410: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
  0x10000373c420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000373c430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000373c440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10000373c450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==7025==ABORTING

POC FILE:https://github.com/fantasy7082/image_test/blob/master/013-stack-buffer-overflow-sbr_hfadj_1287
@hlef
Copy link
Contributor

hlef commented May 5, 2019

This issue was assigned CVE-2018-20196.

I'm currently preparing a fix, will be PR-ed soon.

hlef added a commit to hlef/faad2 that referenced this issue May 5, 2019
@hlef
sbr_fbt: sbr->M should not exceed MAX_M
0a035b7 
sbr->M is set by derived_frequency_table() from user-passed input
without checking for > MAX_M.

This leads to out-of-bounds accesses later, crashes and potential
security relevant issues. It should be considered a fatal error for
the SBR block.

return error code if sbr->M > MAX_M.

also, in some cases sbr_extension_data() ignores the return value of
calc_sbr_tables, probably assuming that sbr is always valid. It should
almost certainly not do that.

fixes knik0#19 (CVE-2018-20196).
hlef added a commit to hlef/faad2 that referenced this issue Aug 10, 2019
@hlef
sbr_fbt: sbr->M should not exceed MAX_M
3d59279 
sbr->M is set by derived_frequency_table() from user-passed input
without checking for > MAX_M.

This leads to out-of-bounds accesses later, crashes and potential
security relevant issues. It should be considered a fatal error for
the SBR block.

return error code if sbr->M > MAX_M.

also, in some cases sbr_extension_data() ignores the return value of
calc_sbr_tables, probably assuming that sbr is always valid. It should
almost certainly not do that.

fixes knik0#19 (CVE-2018-20196).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hlef @fantasy7082