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-691 Insufficient Control Flow Management After Refactoring The Code #5601
Conversation
|
hi @MathiasVP. |
This looks like two queries in one file, they should be split up. The while/for query looks quite good, the arithmetic query is a promising idea but the QL still needs work.
...experimental/Security/CWE/CWE-691/InsufficientControlFlowManagementAfterRefactoringTheCode.c
Outdated
Show resolved
Hide resolved
...experimental/Security/CWE/CWE-691/InsufficientControlFlowManagementAfterRefactoringTheCode.c
Show resolved
Hide resolved
...rimental/Security/CWE/CWE-691/InsufficientControlFlowManagementAfterRefactoringTheCode.qhelp
Outdated
Show resolved
Hide resolved
...xperimental/Security/CWE/CWE-691/InsufficientControlFlowManagementAfterRefactoringTheCode.ql
Show resolved
Hide resolved
cpp/ql/test/experimental/query-tests/Security/CWE/CWE-691/semmle/tests/test.c
Outdated
Show resolved
Hide resolved
...xperimental/Security/CWE/CWE-691/InsufficientControlFlowManagementAfterRefactoringTheCode.ql
Outdated
Show resolved
Hide resolved
| not this.getParent*() instanceof AssignBitwiseOperation and | ||
| not this.getParent*() instanceof AssignArithmeticOperation and | ||
| not this.getParent*() instanceof EqualityOperation and | ||
| not this.getParent*() instanceof RelationalOperation |
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.
Can you briefly explain the purpose of all these exceptions? Do you just want something along the lines of :
(
this.getParent() instanceof IfStmt or
this.getParent() instanceof BinaryLogicalOperation
) and
not this.isConstant()
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 want to remove from the consideration of the situation:
AssignBitwiseOperationif(a&=((b+c)&&(d+e)))AssignArithmeticOperationif((a*=(b+c))&&())EqualityOperationif((a+b)==3)RelationalOperationif((a+b)>3)
I have been working on optimizing this part. but unfortunately I haven't found a more beautiful view yet.
your proposal looks very nice and concise. but this will reveal situations that I am not looking for.
eg:
func(a+b&&c+d) or a==b+c&&d+e
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 discovered another false detection situation and unfortunately I have to complicate this construction.
if you do not mind, I would close this recommendation as done?
| } | ||
|
|
||
| /** Holds when a comparison expression exists. */ | ||
| predicate compareWithOutZero() { |
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.
What are we trying to establish here?
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.
the idea was to detect situations when an expression has no comparisons with zero, but has comparisons with something else.
now I see that it is better to remove this predicate by correcting the work of the previous one.
I'll figure out how to do it.
Thank you.
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.
unfortunately I don't see any other way to exclude null comparison and check for non-null comparison, how to use two predicates.
if I leave one corrected predicate, it will find any non-null comparison and does not guarantee that there is no null.
maybe I'm confused.
but the original version works as I intended.
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.
if you do not mind, I also suggest leaving this site unchanged?
|
I was trying to make a union query that detects error situations after refactoring.
perhaps my words will be more convincing if you take a look at the arithmetic in the condition. as to a more complex expression, the presence of a comparison not with zero elsewhere in the code, no work in a loop, no work with a pointer and a value. you have an aggregation of requests by type, by placing them in single folders, in this situation it is still too early, and by dividing requests we risk losing their connectivity in the future. in any case it is up to you to decide therefore I am waiting for your instructions. |
|
thanks for your corrections. |
...xperimental/Security/CWE/CWE-691/InsufficientControlFlowManagementAfterRefactoringTheCode.ql
Show resolved
Hide resolved
|
I still think I'd prefer if this were split into two queries, so that users have more fine grained control about which parts they're interested in. But I think this is OK in experimental (and we can always change it later). There are still a couple of other comments to address, I will merge this when you're done. |
thanks for the opportunity to leave this request as it is. |
|
There's a merge conflict with the existing |
Yes of course. |
OK, time we merge this.
Here are some runs of the query on LGTM:
- the whole query: https://lgtm.com/query/3548450999479559284/
- just the
UsingArithmeticInComparisoncase: https://lgtm.com/query/2789590730408126002/ (the query does what it is supposed to, but some of the results look like they are intended to be that way) - just the
UsingWhileAfterWhilecase: https://lgtm.com/query/589998443415799114/ (no results found on these projects)
Good day.
This PR looks for situations of losses after refactoring. Two situations are considered. The first forgotten empty while after the loop. And arephmetics in comparison.
the first case is quite rare.
and can lead to an impact on the availability of resources. (hang)
but the second is widely represented.
and is more often influenced by the logic of the program
I tried to remove the false detection as much as possible.
Information about found and accepted fix in the project:
axboe/fio#1194