-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Swift: Query for escaping parameters of unsafe closures #13706
base: main
Are you sure you want to change the base?
Conversation
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.
Good early results, this looks promising.
ints.withUnsafeBytes({(p: UnsafeRawBufferPointer) in v.field = p}) // BAD | ||
print(v.field) | ||
|
||
ints.withUnsafeBytes(myPrint) // GOOD |
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.
Another variant here would be calling a member function that stores the pointer argument in the object it's called on for later use. The effect is similar to the v.field = p
case.
|
||
predicate allowImplicitRead(DataFlow::Node node, DataFlow::ContentSet c) { | ||
isSink(node, _) and | ||
c = any(DataFlow::ContentSet set) |
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.
This looks like a cartesian product - might be a performance issue.
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.
Yes, it is (and I hit the performance issue on a real database). I've shrunk it by narrowing the sinks.
swift/ql/src/queries/Security/CWE-825/UnsafePointerEscapesClosure.ql
Outdated
Show resolved
Hide resolved
QHelp previews: swift/ql/src/queries/Security/CWE-825/UnsafePointerEscapesClosure.qhelpUnsafe pointer escapes closureCertain functions take a closure and pass a temporary pointer into it. If this pointer escapes from the closure and is used outside it, memory corruption may occur. RecommendationDo not use temporary pointers outside the closure they are passed to. ExampleIn the first example below, the pointer is returned from the closure, potentially leading to memory corruption. In the second example, all work with the pointer is done inside the closure, and it is not returned.
References
|
) | ||
} | ||
|
||
additional predicate isUnsafePointerFunction(Function f) { | ||
exists(CallExpr call | | ||
isUnsafePointerCall(call) and | ||
f.getAnAccess() = call.getArgument(0).getExpr() | ||
f.getAnAccess() = call.getAnArgument().getExpr() |
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.
Is it safe that this can match arguments other than the intended closure? If it's possible to pass a closure or function to another argument that is.
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.
We might need to revisit this if there's a case where the function takes multiple closures, but everything I've modeled only takes one closure argument.
ints.withUnsafeBytes({(p: UnsafeRawBufferPointer) in | ||
v.field = p | ||
return 1 | ||
}) // BAD |
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's the issue with implicit returns? Surely we will see them in real world code.
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 issue is that we were picking up the implicit return of the assignment, but not the field being assigned. This is currently not detected... I think there's some missing flow for closure captures.
* @kind path-problem | ||
* @id swift/unsafe-pointer-escapes-closure | ||
* @tags security | ||
* external/cwe/cwe-825 |
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.
Needs precision, severity and security-severity tags. I guess we want to test with a near-final version before choosing a precision.
|
||
<references> | ||
<li><a href="https://developer.apple.com/documentation/swift/array/withunsafebytes(_:)">withUnsafeBytes</a></li> | ||
</references> |
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 do you think about linking to https://www.kodeco.com/7181017-unsafe-swift-using-pointers-and-interacting-with-c as well?
No description provided.