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 getString(util/decompile.c:332) #116

Closed
fantasy7082 opened this issue Mar 7, 2018 · 1 comment
Closed

heap-buffer-overflow in getString(util/decompile.c:332) #116

fantasy7082 opened this issue Mar 7, 2018 · 1 comment

Comments

@fantasy7082
Copy link

Hi, i found a heap-buffer-overflow bug in the libming 0.4.8, the details are below(ASAN):

./swftocxx 008-heap-over-swf /dev/null 
header indicates a filesize of 522 but filesize is 2748
#include <mingpp.h>


main(){
SWFMovie* m = new SWFMovie(48);

Ming_setScale(1.0);
m->setRate(48.187500);
m->setDimension(3992, 3680);

// SWF_SETBACKGROUNDCOLOR 
m->setBackground(0x30, 0x30, 0x30);

// SWF_DEFINESPRITE 

	//  MovieClip 12336 
SWFMovieClip* character12336 = new SWFMovieClip(); // 12336 frames 

// SWF_END 

// SWF_EXPORTASSETS 
m->addExport(character12336,"0000000000000000000");
m->writeExports();

// SWF_INITACTION 
// Might be more appropriate to use addInitAction here
m->add(new SWFInitAction(=================================================================
==40985==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e954 at pc 0x7f81d27439f5 bp 0x7ffd9ce95a80 sp 0x7ffd9ce95210
WRITE of size 5 at 0x60200000e954 thread T0
    #0 0x7f81d27439f4 in __interceptor_vsprintf (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x619f4)
    #1 0x7f81d2743cc9 in __interceptor_sprintf (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x61cc9)
    #2 0x410de2 in getString /root/libming-asan/util/decompile.c:332
    #3 0x413c38 in decompileArithmeticOp /root/libming-asan/util/decompile.c:1044
    #4 0x41e803 in decompileAction /root/libming-asan/util/decompile.c:3310
    #5 0x41eba0 in decompileActions /root/libming-asan/util/decompile.c:3419
    #6 0x41b07e in decompileIF /root/libming-asan/util/decompile.c:2581
    #7 0x41e715 in decompileAction /root/libming-asan/util/decompile.c:3260
    #8 0x41eba0 in decompileActions /root/libming-asan/util/decompile.c:3419
    #9 0x41eccd in decompile5Action /root/libming-asan/util/decompile.c:3441
    #10 0x40d221 in outputSWF_INITACTION /root/libming-asan/util/outputscript.c:1860
    #11 0x40e331 in outputBlock /root/libming-asan/util/outputscript.c:2083
    #12 0x40f3d9 in readMovie /root/libming-asan/util/main.c:286
    #13 0x40fb0e in main /root/libming-asan/util/main.c:359
    #14 0x7f81d1b0f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #15 0x401b58 in _start (/usr/local/libming-asan/bin/swftocxx+0x401b58)

0x60200000e954 is located 0 bytes to the right of 4-byte region [0x60200000e950,0x60200000e954)
allocated by thread T0 here:
    #0 0x7f81d277a602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x410d8c in getString /root/libming-asan/util/decompile.c:331
    #2 0x413c38 in decompileArithmeticOp /root/libming-asan/util/decompile.c:1044
    #3 0x41e803 in decompileAction /root/libming-asan/util/decompile.c:3310
    #4 0x41eba0 in decompileActions /root/libming-asan/util/decompile.c:3419
    #5 0x41b07e in decompileIF /root/libming-asan/util/decompile.c:2581
    #6 0x41e715 in decompileAction /root/libming-asan/util/decompile.c:3260
    #7 0x41eba0 in decompileActions /root/libming-asan/util/decompile.c:3419
    #8 0x41eccd in decompile5Action /root/libming-asan/util/decompile.c:3441
    #9 0x40d221 in outputSWF_INITACTION /root/libming-asan/util/outputscript.c:1860
    #10 0x40e331 in outputBlock /root/libming-asan/util/outputscript.c:2083
    #11 0x40f3d9 in readMovie /root/libming-asan/util/main.c:286
    #12 0x40fb0e in main /root/libming-asan/util/main.c:359
    #13 0x7f81d1b0f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 __interceptor_vsprintf
Shadow bytes around the buggy address:
  0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9cf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9d20: fa fa fa fa fa fa fa fa fa fa[04]fa fa fa 00 05
  0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9d40: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9d50: fa fa fd fd fa fa 00 01 fa fa fd fa fa fa fd fa
  0x0c047fff9d60: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
  0x0c047fff9d70: fa fa 00 01 fa fa 03 fa fa fa 06 fa fa fa fd 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
  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
==40985==ABORTING

POC FILE:https://github.com/fantasy7082/image_test/blob/master/008-heap-over-swf

@hlef
Copy link
Contributor

hlef commented Mar 12, 2018

Reproduced on latest master.

It looks like only 4 bytes are malloc-ed, assuming that passed register number is only two digits, which happens to be false.

t=malloc(4); /* Rdd */
sprintf(t,"R%d", act->p.RegisterNumber );
return t;

FTR, this issue was assigned number CVE-2018-7867.

hlef added a commit to hlef/libming that referenced this issue Mar 16, 2018
getString is allocating a 4-bytes buffer to store an 'R' and an
8-bit number.

t=malloc(4); /* Rdd */
sprintf(t,"R%d", act->p.RegisterNumber );
return t;

Since up to three digits can be required to store the 8-bit
number, the buffer has to be 5 bytes long.

In this commit we also fix the PUSH_DOUBLE case by dynamically
computing the required buffer size.

This commit fixes libming#116 (CVE-2018-7867).
hlef added a commit to hlef/libming that referenced this issue Mar 21, 2018
getString is allocating a 4-bytes buffer to store an 'R' and an
8-bit number.

t=malloc(4); /* Rdd */
sprintf(t,"R%d", act->p.RegisterNumber );
return t;

Since up to three digits can be required to store the 8-bit
number, the buffer has to be 5 bytes long.

In this commit we also fix the PUSH_DOUBLE case by dynamically
computing the required buffer size.

This commit fixes libming#116 (CVE-2018-7867).
hlef added a commit to hlef/libming that referenced this issue Mar 21, 2018
getString is allocating a 4-bytes buffer to store an 'R' and an
8-bit number.

t=malloc(4); /* Rdd */
sprintf(t,"R%d", act->p.RegisterNumber );
return t;

Since up to three digits can be required to store the 8-bit
number, the buffer has to be 5 bytes long.

In this commit we also fix the PUSH_DOUBLE case by dynamically
computing the required buffer size.

This commit fixes libming#116 (CVE-2018-7867).
@strk strk closed this as completed in 3017082 May 20, 2018
hlef added a commit to hlef/libming that referenced this issue May 26, 2018
getString prints a 32 bit integer to a 10 char buffer, but the number
itself has 10 digits so there's an overflow.

Similar to libming#116, same fix.

Fixes libming#111, CVE-2018-7873.
strk pushed a commit that referenced this issue Jul 12, 2020
getString prints a 32 bit integer to a 10 char buffer, but the number
itself has 10 digits so there's an overflow.

Similar to #116, same fix.

Fixes #111, CVE-2018-7873.
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

No branches or pull requests

2 participants