#475 layer2.c: buffer overread vulnerability in the II_step_one function

[Hugo Lefeuvre]

Hi,

Agostino Sarubbo ago@gentoo.org published informations about the following security issue on his website, some weeks ago:

# lame -f -V 9 $FILE out.wav
==27479==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f598d317f20 at pc 0x7f598d2b246b bp 0x7ffe780cf310 sp 0x7ffe780cf308
READ of size 2 at 0x7f598d317f20 thread T0
    #0 0x7f598d2b246a in II_step_one /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/mpglib/layer2.c:144:36
    #1 0x7f598d2b246a in decode_layer2_frame /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/mpglib/layer2.c:375
    #2 0x7f598d29b377 in decodeMP3_clipchoice /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/mpglib/interface.c:611:13
    #3 0x7f598d298c13 in decodeMP3 /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/mpglib/interface.c:696:12
    #4 0x7f598d259092 in decode1_headersB_clipchoice /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/libmp3lame/mpglib_interface.c:149:11
    #5 0x7f598d25e94a in hip_decode1_headersB /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/libmp3lame/mpglib_interface.c:436:16
    #6 0x7f598d25e94a in hip_decode1_headers /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/libmp3lame/mpglib_interface.c:379
    #7 0x51e984 in lame_decode_fromfile /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/get_audio.c:2089:11
    #8 0x51e984 in read_samples_mp3 /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/get_audio.c:877
    #9 0x51e984 in get_audio_common /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/get_audio.c:785
    #10 0x51e4fa in get_audio /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/get_audio.c:688:16
    #11 0x50f776 in lame_encoder_loop /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/lame_main.c:456:17
    #12 0x50f776 in lame_encoder /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/lame_main.c:531
    #13 0x50c43f in lame_main /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/lame_main.c:707:15
    #14 0x510793 in c_main /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/main.c:470:15
    #15 0x510793 in main /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/frontend/main.c:438
    #16 0x7f598be51680 in __libc_start_main /tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/csu/../csu/libc-start.c:289
    #17 0x41c998 in _init (/usr/bin/lame+0x41c998)

0x7f598d317f20 is located 0 bytes to the right of global variable 'alloc_2' defined in '/var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/mpglib/l2tables.h:118:24' (0x7f598d317de0) of size 320
SUMMARY: AddressSanitizer: global-buffer-overflow /var/tmp/portage/media-sound/lame-3.99.5-r1/work/lame-3.99.5/mpglib/layer2.c:144:36 in II_step_one
Shadow bytes around the buggy address:
  0x0febb1a5af90: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0febb1a5afa0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0febb1a5afb0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0febb1a5afc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0febb1a5afd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0febb1a5afe0: 00 00 00 00[f9]f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0febb1a5aff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0febb1a5b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0febb1a5b010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0febb1a5b020: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0febb1a5b030: 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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  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
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==27479==ABORTING

blog post: https://blogs.gentoo.org/ago/2017/06/17/lame-global-buffer-overflow-in-ii_step_one-layer2-c/

As far as I am aware, no bug report has been filled for this issue yet.

As member of the Debian LTS team, I'd like to fix this issue in our lame package, but I have difficulties reproducing it. Are you aware of this vulnerability ? Is a fix planned for 2.100 ?

Best Regards,
Hugo

[Hugo Lefeuvre]

I meant 3.100.

Also, three other similar vulnerabilities have been reported:
https://security-tracker.debian.org/tracker/CVE-2017-9870
https://security-tracker.debian.org/tracker/CVE-2017-9871
https://security-tracker.debian.org/tracker/CVE-2017-9872

Please let me know if I should open a bug report for each of them.

[Robert Hegemann]

If it's the same as bug #470 "global-buffer-overflow mpglib/layer2.c:144 II_step_one"
https://sourceforge.net/p/lame/bugs/470/
then it is already fixed in CVS and will be in version 3.100.

[Hugo Lefeuvre]

Unfortunately I couldn't reproduce the issue on my system, so I cannot be 100% sure they are duplicates. This is probable, however.

Could you try to reproduce it ? You can find a reproducer in the original blog post:
https://blogs.gentoo.org/ago/2017/06/17/lame-global-buffer-overflow-in-ii_step_one-layer2-c/

CVE-2017-98{70,71,72} are completely different issues. I have opened separate bug reports for them.

[Henri Salo]

Moritz commented in IRC that starting with stretch the Debian packages uses libsndfile for parsing all that RIFF files, so it's not affected by all those upstream crashes in the internal parser. This might be the cause of the reproducing issues. In my 2017-09-07 comment I only tested with CVS version.

This bug should be closed.

[Robert Hegemann]

libsndfile does not decode MPEG files, so that should not make any difference in this case.

[Henri Salo]

Already fixed. Please don't open up issues in the bug tracker if you are not able to reproduce the issue, thanks.

[Robert Hegemann]

fixed in version 3.100