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-use-after-free in decompileIF #105

Closed
gy741 opened this issue Jan 27, 2018 · 5 comments · Fixed by #108
Closed

heap-use-after-free in decompileIF #105

gy741 opened this issue Jan 27, 2018 · 5 comments · Fixed by #108

Comments

@gy741
Copy link

gy741 commented Jan 27, 2018

Hello.

I found a heap-use-after-free bug in libming.

Please confirm.

Thanks.

Summary: heap-use-after-free
OS: CentOS 7 64bit
Version: 3120f1c
PoC Download: free_decompileIF.zip

Steps to reproduce:
1.Download the .POC files.
2.Compile the source code with ASan.
3.Execute the following command
: ./swftocxx $POC /dev/null

=================================================================
==26617==ERROR: AddressSanitizer: heap-use-after-free on address 0x60e0000000d0 at pc 0x00000055d960 bp 0x7fffa1302440 sp 0x7fffa1302438
READ of size 1 at 0x60e0000000d0 thread T0
    #0 0x55d95f in decompileIF /home/karas/libming/util/decompile.c:2390:49
    #1 0x5723eb in decompileActions /home/karas/libming/util/decompile.c:3420:6
    #2 0x5723eb in decompile5Action /home/karas/libming/util/decompile.c:3442
    #3 0x521b0d in outputSWF_DOACTION /home/karas/libming/util/outputscript.c:1552:29
    #4 0x528d95 in readMovie /home/karas/libming/util/main.c:286:4
    #5 0x528d95 in main /home/karas/libming/util/main.c:359
    #6 0x7fba679381c0 in __libc_start_main /build/glibc-CxtIbX/glibc-2.26/csu/../csu/libc-start.c:308
    #7 0x419d59 in _start (/home/karas/libming/run/bin/swftocxx+0x419d59)

0x60e0000000d0 is located 144 bytes inside of 160-byte region [0x60e000000040,0x60e0000000e0)
freed by thread T0 here:
    #0 0x4d66f8 in realloc (/home/karas/libming/run/bin/swftocxx+0x4d66f8)
    #1 0x57bf64 in parseSWF_ACTIONRECORD /home/karas/libming/util/parser.c:1076:40

previously allocated by thread T0 here:
    #0 0x4d66f8 in realloc (/home/karas/libming/run/bin/swftocxx+0x4d66f8)
    #1 0x57bf64 in parseSWF_ACTIONRECORD /home/karas/libming/util/parser.c:1076:40

SUMMARY: AddressSanitizer: heap-use-after-free /home/karas/libming/util/decompile.c:2390:49 in decompileIF
Shadow bytes around the buggy address:
  0x0c1c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8000: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
=>0x0c1c7fff8010: fd fd fd fd fd fd fd fd fd fd[fd]fd fa fa fa fa
  0x0c1c7fff8020: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8030: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c1c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8060: 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
==26617==ABORTING

=================
[Acknowledgement]
This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001, Innovation hub for high Performance Computing]

@hlef
Copy link
Contributor

hlef commented Jan 27, 2018

Yes, I could reproduce this issue on a fresh master branch.

I'll investigate the issue and request a CVE id if needed.

Thanks.

@gy741
Copy link
Author

gy741 commented Jan 27, 2018

@hlef

Hello,

There are other open issues in the project. (ex. memory leak/ Bug number )

Are these problems resolved?

Thanks.

@hlef
Copy link
Contributor

hlef commented Jan 27, 2018

If you are speaking about #71, #72, #73 and #74, no, they are not fixed yet (I did not even try to reproduce all of them, that's why they didn't necessarily got a CVE number assigned) and I am probably not going to work on these issues in the next weeks. Feel free to PR. ;)

#104 and the other issues in listfdb are currently being worked on. #102 is a duplicate and should be closed soon.

@hlef
Copy link
Contributor

hlef commented Jan 27, 2018

So, this is in fact a completely new issue. Very similar to #83, the fix will probably look like 1f59763. I'll request a CVE id and submit a fix.

Thanks.

@hlef
Copy link
Contributor

hlef commented Jan 30, 2018

FTR, this issue was assigned id CVE-2018-6359.

hlef added a commit to hlef/libming that referenced this issue Feb 19, 2018
The decompileIF function in util/decompile.c accesses actions
array without checking the validity of n, the user entered index.
This leads to heap-use-after-free issues when n is zero.

This commit addresses this issue by using the OpCode function
which does check input arguments.

This commit fixes libming#105 (CVE-2018-6359).
hlef added a commit to hlef/libming that referenced this issue Feb 19, 2018
The decompileIF function in util/decompile.c accesses actions
array without checking the validity of n, the user entered index.
This leads to heap-use-after-free issues when n is zero.

This commit addresses this issue by using the OpCode function
which does check input arguments.

This commit fixes libming#105 (CVE-2018-6359).
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.
@strk strk closed this as completed in #108 Feb 20, 2018
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