Skip to content

Shared: restrict flow after using implicit read #17262

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

Merged
merged 6 commits into from
Aug 26, 2024

Conversation

asgerf
Copy link
Contributor

@asgerf asgerf commented Aug 20, 2024

After using an implicit read, flow can now only terminate in a sink or continue along edges contributed by Config:isAdditionalFlowStep, but not via other kinds of steps, like simple local flow steps.

This is achieved by treating the implicit read node as a sink if its original node was a sink, and copying any relevant outgoing steps from the original node onto the implicit read node.

asgerf added 5 commits August 23, 2024 11:02
This reveals that some tests were passing for the wrong reasons.
See github#17275
The 'first' field is seen as a TaintInheritingContent, which means any read step for 'first' becomes a taint step too.
This type of taint step does not permit an implicit read before it, because it wasn't contributed by a configuration.
So there is no way for the taint to get out of the collection content before the taint step through '.first'.
The test previously passed because an implicit read at once of the earlier sinks could follow use-use flow down to the receiver of .first,
allowing it to escape the collection content.
@asgerf asgerf force-pushed the shared/implicit-read branch from 781e753 to 8df7fbf Compare August 23, 2024 09:31
@asgerf asgerf marked this pull request as ready for review August 23, 2024 11:30
@asgerf asgerf requested review from a team as code owners August 23, 2024 11:30
@asgerf asgerf added the no-change-note-required This PR does not need a change note label Aug 23, 2024
Copy link
Contributor

@aschackmull aschackmull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks correct to me.

@aschackmull
Copy link
Contributor

Are the dca runs up-to-date and ok? If so, then this looks ready to merge.

@asgerf
Copy link
Contributor Author

asgerf commented Aug 26, 2024

Yes, the DCA runs are up to date. (The C++ report is messed up due to a failure in JavaScriptCore, but that's also failing on nightly)

@asgerf asgerf merged commit 592e2ea into github:main Aug 26, 2024
40 of 41 checks passed
asgerf added a commit to asgerf/codeql that referenced this pull request Aug 27, 2024
@jketema
Copy link
Contributor

jketema commented Aug 27, 2024

This will need to be backed out. The C++ DCA failure on Wireshark is a serious regression where we now get a timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants