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
Null pointer dereference vulnerability in getName (util/decompile.c:380) #121
Comments
|
Reproduced on latest master. AFAIK this issue wasn't assigned a CVE number. |
|
Related to #122 maybe? Same file/function. |
|
It looked like a different issue to me. This file contains a lot of functions with a lot of different flaws, so it isn't really surprising to find different issues in this same small portion of code. I'm currently investigating it and will PR a fix soon. |
Whenever getString or getName are called with an act such that act->p.String is a NULL pointer, a NULL pointer dereference might happen (strlen(act->p.string) is called). In this commit we add checks at the beginning of the PUSH_STRING block so that a warning is displayed and an empty string is returned in this case. This patch fixes libming#121.
Whenever getString or getName are called with an act such that act->p.String is a NULL pointer, a NULL pointer dereference might happen (strlen(act->p.string) is called). In this commit we add checks at the beginning of the PUSH_STRING block so that a warning is displayed and an empty string is returned in this case. This patch fixes libming#121.
|
I've written a patch for this issue, but I'm not sure yet that it's the right one (or at least that it's enough). In fact, my patch simply adds checks handling the case where |
|
After extensive debugging it looks like there is a very nasty bug underneath. Here are some interesting things: So, after manually verifying all In order to see where, let's set a watchpoint: So, now we know that our Why ? If we look at the addresses, it appears that Why ? Maybe something wrong with pop(), or some bug earlier. I'll have to push the investigations further. |
|
Let's track calls to Now I can explain why pop is returning twice the exact same result: It's because
|
|
Well, after some careful thoughts on the subject, I think that shallow copy is wrong in this case. In the SWF specification, a String is defined as a sequential list of bytes terminated by the null character byte. This means that whenever a String is at the top of the stack, i.e. pushdup should perform a deep copy. I'll update the PR accordingly. |
Until now, the element duplication in pushdup was performed via t->val = Stack->val. While this is perfectly fine for integer/double/register values, this may create nasty, hard to debug issues with Strings. In fact, when called with a String at the top of the stack, pushdup would only push *a reference* to the same String element (shallow copy), later allowing to modify several stack elements at once, which may potentially lead to NULL pointer dereferences or any other unspecified impact. In this patch we implement deep copy in pushdup: * If the type of the stack element is 's' (for String), we allocate a new buffer and copy the String into it. * Otherwise we simply proceed as before, that is we do t->val = Stack->val which is perfectly fine since we are not dealing with pointers. This patch is the last part of the patch for libming#121 (fixes libming#121), which should now be completely fixed.
Until now, the element duplication in pushdup was performed via t->val = Stack->val. While this is perfectly fine for integer/double/register values, this may create nasty, hard to debug issues with Strings. In fact, when called with a String at the top of the stack, pushdup would only push *a reference* to the same String element (shallow copy), later allowing to modify several stack elements at once, which may potentially lead to NULL pointer dereferences or any other unspecified impact. In this patch we implement deep copy in pushdup: * If the type of the stack element is 's' (for String), we allocate a new buffer and copy the String into it. * Otherwise we simply proceed as before, that is we do t->val = Stack->val which is perfectly fine since we are not dealing with pointers. This patch is the last part of the patch for libming#121 (fixes libming#121), which should now be completely fixed.
|
FTR, this issue was assigned id CVE-2018-9165. |
Whenever getString or getName are called with an act such that act->p.String is a NULL pointer, a NULL pointer dereference might happen (strlen(act->p.string) is called). In this commit we add checks at the beginning of the PUSH_STRING block so that a warning is displayed and an empty string is returned in this case. This patch fixes #121.
Until now, the element duplication in pushdup was performed via t->val = Stack->val. While this is perfectly fine for integer/double/register values, this may create nasty, hard to debug issues with Strings. In fact, when called with a String at the top of the stack, pushdup would only push *a reference* to the same String element (shallow copy), later allowing to modify several stack elements at once, which may potentially lead to NULL pointer dereferences or any other unspecified impact. In this patch we implement deep copy in pushdup: * If the type of the stack element is 's' (for String), we allocate a new buffer and copy the String into it. * Otherwise we simply proceed as before, that is we do t->val = Stack->val which is perfectly fine since we are not dealing with pointers. This patch is the last part of the patch for #121 (fixes #121), which should now be completely fixed.
Hi, i found a null pointer dereference bug in the libming 0.4.8. It crashed in function getName .the details are below(ASAN):
POC FILE:https://github.com/fantasy7082/image_test/blob/master/013-NULL-ptr-swf
The text was updated successfully, but these errors were encountered: