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.

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

heap buffer overflow in decompileCALLFUNCTION #83

Closed
bestshow opened this issue Jun 8, 2017 · 1 comment · Fixed by #90
Closed

heap buffer overflow in decompileCALLFUNCTION #83

bestshow opened this issue Jun 8, 2017 · 1 comment · Fixed by #90

Comments

@bestshow
Copy link

bestshow commented Jun 8, 2017

On libming latest version, a heap buffer overflow was found in function decompileCALLFUNCTION .

#swftocxx $FILE out
=================================================================
heap-buffer-overflow on address 0x6120000002f0 at pc 0x0000005524b1 bp 0x7ffe6c0b9700 sp 0x7ffe6c0b96f8
READ of size 1 at 0x6120000002f0 thread T0
    #0 0x5524b0 in decompileCALLFUNCTION /home/haojun/Downloads/libming-master/util/decompile.c:2864:2
    #1 0x5524b0 in decompileAction /home/haojun/Downloads/libming-master/util/decompile.c:3264
    #2 0x5875eb in decompileActions /home/haojun/Downloads/libming-master/util/decompile.c:3401:6
    #3 0x5875eb in decompile5Action /home/haojun/Downloads/libming-master/util/decompile.c:3423
    #4 0x52a0c5 in outputSWF_DOACTION /home/haojun/Downloads/libming-master/util/outputscript.c:1548:29
    #5 0x531311 in readMovie /home/haojun/Downloads/libming-master/util/main.c:277:4
    #6 0x531311 in main /home/haojun/Downloads/libming-master/util/main.c:350
    #7 0x7ff575a06b34 in __libc_start_main /usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274
    #8 0x41ae7b in _start (/home/haojun/Downloads/libming-afl-build/bin/swftocxx+0x41ae7b)

0x6120000002f0 is located 40 bytes to the right of 264-byte region [0x6120000001c0,0x6120000002c8)
allocated by thread T0 here:
    #0 0x4dff2d in calloc /home/haojun/Downloads/llvm-clang/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x5beb8c in parseSWF_DOACTION /home/haojun/Downloads/libming-master/util/parser.c:2428:3
    #2 0x7ff575a06b34 in __libc_start_main /usr/src/debug/glibc-2.17-c758a686/csu/../csu/libc-start.c:274

heap-buffer-overflow /home/haojun/Downloads/libming-master/util/decompile.c:2864:2 in decompileCALLFUNCTION
Shadow bytes around the buggy address:
  0x0c247fff8000: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c247fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c247fff8020: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
  0x0c247fff8030: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c247fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c247fff8050: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa[fa]fa
  0x0c247fff8060: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c247fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c247fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c247fff8090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c247fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==17349==ABORTING

testcase : https://github.com/bestshow/p0cs/blob/master/heap-buffer-overflow-in_decompileCALLFUNCTION
Credit : ADLab of Venustech

@hlef
Copy link
Contributor

hlef commented Oct 6, 2017

decompileCALLFUNCTION is checking the type of the previous action by getting the n - 1th element of the actions array. This is fine as long as n > 1, otherwise this is overflow prone.

Fix: Replace

actions[n-1].SWF_ACTIONRECORD.ActionCode == SWFACTION_PUSH

by

n > 1 && actions[n-1].SWF_ACTIONRECORD.ActionCode == SWFACTION_PUSH.

I'll submit a PR after merge of #89.

For the record, this issue has been assigned ID CVE-2017-11734.

hlef added a commit to hlef/libming that referenced this issue Oct 6, 2017
Make sure that n > 1 before checking for the previous action in the
actions array, otherwise an overflow may occur.

This commit fixes CVE-2017-11734 (fixes libming#83).
hlef added a commit to hlef/libming that referenced this issue Oct 6, 2017
Make sure that n > 0 before checking for the previous action in the
actions array, otherwise an overflow may occur.

This commit fixes CVE-2017-11734 (fixes libming#83).
@strk strk closed this as completed in #90 Oct 11, 2017
hlef added a commit to hlef/libming that referenced this issue Feb 19, 2018
Instead of directly accessing the actions array without checks
for the value of n (which may lead to heap buffer overflow etc,
see libming#83 or libming#105), use the dedicated OpCode function.
hlef added a commit to hlef/libming that referenced this issue Feb 19, 2018
Instead of directly accessing the actions array without checks
for the value of n (which may lead to heap buffer overflow etc,
see libming#83 or libming#105), use the dedicated OpCode function.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants