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

There is crash in listswf tool of libming by a crafted input that will lead to a DoS damage. #86

owl337 opened this issue Jun 23, 2017 · 4 comments


Copy link

commented Jun 23, 2017

The POC is got from


The debugging information is as follows:

There is previous incorrect operation cause si->size too large that make malloc memory failure. It leads the program crash in outputtxt.c:2229 , the details is below.

outputtxt.c:2228 buffer = malloc(si->Size+1);//si->Size is too large buffer is NULL,malloc failure
outputtxt.c:2229 memset(buffer, 0, si->Size+1);//cause NULL pointer deference

$gdb ./listswf
(gdb) set args POC2
(gdb) r
(gdb) bt
(gdb) bt
#0 __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:78
#1 0x000000000040e0f3 in outputABC_STRING_INFO (si=)
at outputtxt.c:2229
#2 outputStringConstant (abc=, strIndex=)
at outputtxt.c:2449
#3 0x000000000040ec79 in outputABC_METADATA_INFO (abc=0x676250,
mi=0x7ffff00020f8) at outputtxt.c:2563
#4 0x000000000040ff01 in outputABC_FILE (abc=0x676250) at outputtxt.c:2772
#5 0x000000000040b0ca in outputBlock (type=, blockp=0x676240,
stream=) at outputtxt.c:2933
#6 0x00000000004120c6 in readMovie (f=) at main.c:277
#7 main (argc=, argv=) at main.c:350


This vulnerability is detected by team OWL337, with our custom fuzzer collAFL. Please contact and if you need more info about the team, the tool or the vulnerability.


This comment has been minimized.

Copy link

commented Jul 19, 2017

This has been assigned CVE-2017-9989


This comment has been minimized.

Copy link

commented Jul 19, 2017


This comment has been minimized.

Copy link

commented Oct 11, 2017

parseABC_STRING_INFO is passing sinfo->Size (type U30 = unsigned long) as size argument to readBytes (type int). This is a lossy cast, and in this case the value becomes negative.

Please, note that this issue isn't fixed by 2027b24, the overflow is still present.

A possible fix would be to change readBytes so it takes an unsigned long as size argument.

This should not be a problem because if readBytes is called with an int as size argument, it will be cast to unsigned long, which is guaranteed to be fine.


This comment has been minimized.

Copy link

commented Oct 11, 2017

@strk strk closed this in 1a1d270 Oct 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.