cpp - Using the return value of a strcpy or related string copy function in an if statement#695
Conversation
…ion in an if statement
jbj
left a comment
There was a problem hiding this comment.
Thank you for contributing this query. I tested it on 49 projects, and it gave no results. That's a good sign since hopefully the errors found with this query are very rare.
|
|
||
| from IfStmt ifs, | ||
| FunctionCall func | ||
| where isStringComparisonFunction( func.getTarget().getQualifiedName() ) |
There was a problem hiding this comment.
In C++, when imported via #include <cstring>, these functions are named std::strcpy etc. If you use getName instead of getQualifiedName, you'll match those as well. That might also match unrelated functions like foo::bar::strcpy, but hopefully nobody names a function strcpy without ensuring it has the same behaviour as the one from the standard library.
There was a problem hiding this comment.
It is a simple change, and hopefully it will not cause false positives, as you mentioned, it is very unlikely that somebody would name a function strcpy without it behaving similarly to the standard library. Changing it
| or functionName = "_mbsncpy_l" | ||
| } | ||
|
|
||
| from IfStmt ifs, |
There was a problem hiding this comment.
Why limit this to IfStmt and to particular operations in its condition? Shouldn't the warning apply at any point where the result of a string copy function is converted to a Boolean type? That would be like in #211.
There was a problem hiding this comment.
I added conversions to Boolean values, and also adding a dataflow to the result being used in logical/equality operations. Running a few more tests to make sure I am not missing anything.
There was a problem hiding this comment.
I tested the query again: https://lgtm.com/query/4616339080794271386/
There are results in Microsoft CoreCLR that I presume to be false positives. I suggest using only intraprocedural data flow (DataFlow::localFlow) to avoid results like that.
There was a problem hiding this comment.
Fixed. I run the same tests again with the new prototype, and I found no false positives. Thanks
| and func = eop.getAChild() | ||
| ) | ||
| ) | ||
| select func, "Incorrect use of function " + func.getTarget().getQualifiedName() + ". Verify the logic and replace with a secure string copy function, or a string comparison function." |
There was a problem hiding this comment.
We generally don't give advice in alert messages on how to remedy the problem. It's okay for an alert to be terse. I suggest
"Return value of " + func.getTarget().getQualifiedName() + " used in condition"
There was a problem hiding this comment.
Sounds good. I will change the string to only indicate that the return value from these functions does not reserve any value to indicate an error.
There was a problem hiding this comment.
NOTE: In C++, this new approach is showing some cases twice (boolean conversion && used in a logical condition), but otherwise I miss some scenarios.
In C, it works well as there is no implicit boolean type conversion when used in logical conditions
| * @kind problem | ||
| * @problem.severity error | ||
| * @precision high | ||
| * @id cpp/string-copy-function-in-if-condition |
There was a problem hiding this comment.
Depending on how we address some of my other remarks, it may be appropriate to change the id, name, description, and file name.
| { | ||
| } | ||
|
|
||
| if (SomeFunction() && strcpy(szbuf1, "test")) // Bug, binary logical operator |
There was a problem hiding this comment.
Please add a test case that's one more level deep. For example, add a ! in front of strcpy here.
There was a problem hiding this comment.
I think this is the last of my comments that still isn't addressed. I suggest that you change isStringCopyUsedInCondition so it doesn't require that the logical operations are contained in a condition. Don't we also want to flag code like status = !strcpy(s, "foo");?
There was a problem hiding this comment.
I completely forgot about this comment during the break. Sorry about that.
|
It seems like the QHelp-Preview check failed, but I have no visibility into the failure. Please let me know what I should change. |
|
C++ QL Tests failed (nuget failure during QL install step). I am not sure if there is anything I can do to fix it on my side. |
|
Thanks. I've triggered our Jenkins-based tests instead of the broken ones, and I'll follow up tomorrow when they've completed. |
|
To get rid of the duplicates, you can pick one of the messages to have precedence and suppress the other one when it's there. Change to |
I changed to detect any logical operation usage (i.e. !, ==), but I kept usage in a conditional directly as a separate detection condition. I found no false positives on the projects you shared with me previously.
jbj
left a comment
There was a problem hiding this comment.
The tests have passed, so I'll merge this.
Equivalent to http://go.microsoft.com/fwlink/?LinkID=244784