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

CPP: Add query for CWE-476: NULL Pointer Dereference when using exception handling blocks #8245

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

Copy link
Contributor

@ihsinme ihsinme commented Feb 25, 2022

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.

ihsinme and others added 2 commits Mar 15, 2022
Co-authored-by: Geoffrey White <40627776+geoffw0@users.noreply.github.com>
@ihsinme
Copy link
Author

@ihsinme ihsinme commented Mar 15, 2022

Thanks for corrections.

Copy link
Contributor

@geoffw0 geoffw0 left a comment

Some suggestions and questions about the query itself.

vro = va.getTarget() and
vr != vro
) and
pointerDereference(cb, vr, vro) and
Copy link
Contributor

@geoffw0 geoffw0 Mar 23, 2022

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?

Copy link
Contributor Author

@ihsinme ihsinme Apr 2, 2022

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;
   }

Copy link
Contributor

@geoffw0 geoffw0 Apr 4, 2022

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>
@ihsinme
Copy link
Author

@ihsinme ihsinme commented Mar 30, 2022

thanks for your fixes.
I'm a little late with the answer, I hope to answer all your questions soon

@ihsinme ihsinme changed the title en CPP: Add query for CWE-476: NULL Pointer Dereference when using exception handling blocks CPP: Add query for CWE-476: NULL Pointer Dereference when using exception handling blocks Apr 2, 2022
@geoffw0
Copy link

@geoffw0 geoffw0 commented Apr 4, 2022

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?

@ihsinme
Copy link
Author

@ihsinme ihsinme commented Apr 4, 2022

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.
in projects using openexr for example.
https://github.com/mnaydenov/FreeImage-Adv.git

This project has already fixed a similar problem.
RTEMS/rtems-tools#2
https://github.com/RTEMS/rtems-tools.git

I am currently evaluating how to expand the detect if in the first part look for access without operator delete.

For the second part, I don't see extensions yet. I'll be glad for a hint.

@geoffw0
Copy link

@geoffw0 geoffw0 commented Apr 5, 2022

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/

@ihsinme
Copy link
Author

@ihsinme ihsinme commented May 4, 2022

good afternoon @geoffw0

Sorry for the delay in expanding this PR.
https://lgtm.com/query/4145429960886415578/

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.

@geoffw0
Copy link

@geoffw0 geoffw0 commented May 4, 2022

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 ConstructorFieldInit class.

geoffw0
geoffw0 previously approved these changes May 5, 2022
Copy link
Contributor

@geoffw0 geoffw0 left a comment

Great!

@geoffw0
Copy link

@geoffw0 geoffw0 commented May 5, 2022

It looks like there are some new results in the test, and the QL needs to be autoformatted.

@ihsinme
Copy link
Author

@ihsinme ihsinme commented May 5, 2022

@geoffw0
I made changes now you can run checks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants