-
Notifications
You must be signed in to change notification settings - Fork 1.8k
JS: track shell:true more in js/shell-command-constructed-from-input #11858
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
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.
Some questions. Specifically, I would like to establish if api graphs in js has a reason to deviate form the rest or if there is a bug in all of them..
exists(API::Node node | | ||
node.asSink() = sys.getOptionsArg() and | ||
node.getMember("shell").getAValueReachingSink().mayHaveBooleanValue(true) | ||
) | ||
} |
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.
Why is the old bit not covered by the new bit (so that we could have only the new bit)?
Do you happen to have a concrete piece of code that is matched by the old and not the new?
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 are not guarantee that all SystemCommandExecution
have a corresponding API::Node
.
I think there are API::Node
for all of them right now, but if we model more SystemCommandExecution
they might not all have API::Node
s.
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.
Right, I can accept that. I might add a comment before line 162 saying something like "In case sys.getOptionsArg
is not a sink for any API node".
DataFlow::Node getAValueReachingSink() { | ||
result = Impl::trackDefNode(this.asSink()) | ||
or | ||
// in case `asSink()` is not a `SourceNode`. | ||
result = this.asSink() | ||
} |
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 asSink()
is not a SourceNode
, you should simply get a local source for it, is that not good enough? I could se it failing, if rhs(_, _, asSink())
does not hold at all, but then that predicate should perhaps be extended? What is the concrete value that prompted this?
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 asSink() is not a
SourceNode
, you should simply get a local source for it
The problem is that .getALocalSource()
has no result.
A boolean literal is not a SourceNode
, and .getALocalSource()
has no result.
I think SourceNode
in Python is a bit different. I suspect that you are guaranteed that .getALocalSource()
has a result?
The motivation was a boolean literal being written to a property.
Now that I think about it: getAValueReachingSink
adds nothing when we are tracking booleans, I would need a small-step type-backtracker (because that doesn't depend on SourceNode
).
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.
Indeed, in Python there will always be a local source. If nothing else, then the node itself.
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.
LGTM
CVE-2022-22984: TP
Evaluation was unevenful.