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
CPP: Add query for CWE-476: NULL Pointer Dereference when using exception handling blocks #8245
base: main
Are you sure you want to change the base?
Conversation
My initial thoughts. I will need to review the QL in a bit more detail.
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Show resolved
Hide resolved
cpp/ql/test/experimental/query-tests/Security/CWE/CWE-476/semmle/tests/test.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/test/experimental/query-tests/Security/CWE/CWE-476/semmle/tests/test.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/test/experimental/query-tests/Security/CWE/CWE-476/semmle/tests/test.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/test/experimental/query-tests/Security/CWE/CWE-476/semmle/tests/test.cpp
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.cpp
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.qhelp
Outdated
Show resolved
Hide resolved
Co-authored-by: Geoffrey White <40627776+geoffw0@users.noreply.github.com>
Thanks for corrections. |
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Outdated
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Show resolved
Hide resolved
cpp/ql/src/experimental/Security/CWE/CWE-476/DangerousUseOfExceptionBlocks.ql
Show resolved
Hide resolved
vro = va.getTarget() and | ||
vr != vro | ||
) and | ||
pointerDereference(cb, vr, vro) and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding of what's going on here is that we have a try
block containing vr = new ...
, and a catch
block containing delete vr
, but its possible to throw
before the vr = new ...
and reach the delete vr
.
What is vro
for? Do we really need to track two new
allocations to catch this bug?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are absolutely right if we are talking about deletion.
but I wanted to add detection of a problem with access to unallocated memory, as it happened in CVE-2020-15304.
for (size_t i = 0; i < _data->tileBuffers.size(); i++)
{
delete [] _data->tileBuffers[i]->buffer;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand. The delete
expression in the catch block is deleting vr
, but is qualified by something like vro->
, and its vro
that may not have been allocated due to the throw
. In your example immediately above, vro
might be _data
.
Co-authored-by: Geoffrey White <40627776+geoffw0@users.noreply.github.com>
thanks for your fixes. |
Thanks for making the changes - we've definitely made the QL easier to follow! I tried this query on LGTM but I didn't find any results (a few still to finish as I write this). It might be a good idea to start thinking of ways we could widen the query? |
my analysis showed several detections. This project has already fixed a similar problem. I am currently evaluating how to expand the detect if in the first part look for access without operator For the second part, I don't see extensions yet. I'll be glad for a hint. |
For the benefit of my future self and other readers, here's an LGTM run of the query on the two projects mentioned above: https://lgtm.com/query/410819352512416178/ |
good afternoon @geoffw0 Sorry for the delay in expanding this PR. I suggest adding this version of detection, I like the preliminary results. although there are still a number of false positives associated with null initialization. The idea behind the query is that an exception can be thrown when memory is allocated, and if it is freed during processing, then this behavior is undefined. if you don't mind, I'll add that part to the main request. |
The new case seems to be finding good results, though the message will need to explain the problem clearly so that a user can make sense of what they're being shown (it needs to say that if the allocation in the try block fails, then an unallocated pointer will be freed in the catch block). As an improvement, you should be able to spot variables that have been initialized to zero in a constructor initializer list using the |
It looks like there are some new results in the test, and the QL needs to be autoformatted. |
@geoffw0 |
this query looks for access situations for pointer data types in situations where they might not have been allocated. the main situation is the transition to the exception handler, before the allocation of memory. an additional query looks for memory re-freeing situations during exception handling.
CVE-2020-15304
I am currently working on making a change to the actual project.