-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Audit usage of server-side code generation from strings #84816
Comments
Pinging @elastic/kibana-security (Team:Security) |
@watson I know you had made some progress on this a while back. If you still have the branch available, would you be able to reference it here so we don't lose track of your work? |
@legrego 👍 Will pack together what I have and push it to a branch ASAP |
This is the current status: Initially I thought it was possible to simply overwrite the global Instead we need to add official hooks into the However, that PR doesn't work as is (which is also why it was never merged) because it requires some changes to V8 itself. I never got around to making these changes in V8, which is where the work is currently stranded. I believe the details of what needs to be done is documented in the above PR. The TL;DR is that the V8 hooks into Finally I have a WIP commit/branch of Kibana which I pushed to my fork of Kibana which ties all this together: You can see the source here: main...watson:kibana:audit-code-gen |
I took a stab at recreating the original Node.js PR and to work on where in V8 the mentioned changes needed to go. I've created a new draft PR for the purpose of getting help with the V8 changes as I'm not that familiar with the V8 codebase: nodejs/node#48295 |
This is essentially a server-side version of #36311.
Code generation from strings is a powerful tool, but with great power comes...a significant increase in attack surface.
Node.js has a
--disallow-code-generation-from-strings
command line argument that allows us to block this feature altogether. Before we can even consider such a drastic measure, we should audit all places that Kibana directly and indirectly requires this functionality.Ideally, this would run as part of CI for the functional UI tests and fail CI if we find new usages which aren't already known. This will let us work toward removing all existing usages without continuing to add new usages which later have to be addressed. We could also potentially use this same approach as part of dev mode to catch violations which aren't covered by the functional ui tests.
The text was updated successfully, but these errors were encountered: