You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
funcTest(str*string, src core.Source) {
fmt.Sscan(src.Data, &str)
core.Sink(str) // TODO() want "a source has reached a sink"
}
If you're not familiar with Sscan (I wasn't), it essentially splits its first argument (a string) on whitespace and places the resulting strings into its second argument (which has type ...interface{}). (See here for an example of using the closely related Sscanf function).
So, clearly, if the string is tainted, the varargs slice can also be tainted. This slice is implicit, however, and to construct it, in SSA form a slice is made and the arguments are placed into it via Store instructions. Since for Stores we only propagate from the value being stored to the storage location, we can't currently handle this case.
One solution would be to allow taint to propagate backwards through stores. This is likely to cause false positives, however.
The text was updated successfully, but these errors were encountered:
Consider this case:
If you're not familiar with
Sscan
(I wasn't), it essentially splits its first argument (a string) on whitespace and places the resulting strings into its second argument (which has type...interface{}
). (See here for an example of using the closely relatedSscanf
function).So, clearly, if the string is tainted, the
varargs
slice can also be tainted. This slice is implicit, however, and to construct it, in SSA form a slice is made and the arguments are placed into it viaStore
instructions. Since forStore
s we only propagate from the value being stored to the storage location, we can't currently handle this case.One solution would be to allow taint to propagate backwards through stores. This is likely to cause false positives, however.
The text was updated successfully, but these errors were encountered: