Closed Dtr0y-Sec closed 8 months ago
Basically, we've decided to not include --allow-inspector. What would be the usecase for it?
cc: @tniessen
What security guarantees do you expect when access to node:inspector
is granted?
@RafaelGSS
I have a complex ecosystem of microservices running user-entered code, and I plan to use the --experimental-permissions flag to restrict access to container files by fs and to restrict the use of child processes.
On the other hand, my team currently uses inspection mode a lot to remotely debug applications running on Kubernetes in a cloud environment and this helps a lot in bug analysis.
It would be really nice if we had an option to enable inspection mode along with permissions too.
Does this also answer your question @tniessen ?
@Dtr0y-Sec 3df13d5a79 addresses CVE-2023-30587. Simply put, it is rather easy for malicious code to bypass restrictions imposed by the permission model through the node:inspector
API. My understanding is that --allow-inspector
would restore the pre 3df13d5a79 behavior, thus allowing JavaScript code to bypass the permission model. In your case, would that security implication be acceptable?
@tniessen
Is attach necessary to bypass the permission model? Or just being active makes the application vulnerable?
In my scenario, access to inspection mode is restricted to users, only admins can access it for remote debugging. If to exploit the vulnerability it is necessary to access the inspection mode, it would be acceptable for me, but if it is possible to bypass permission model only with the "--allow-inspect" flag activated then it would be a problem.
I would also like to take the opportunity to thank you guys, this feature will solve many security issues that I am currently facing.
@Dtr0y-Sec The problem is that a malicious actor/package can use require('node:inspector')
and manipulate the process memory in a way that they will be able to new Worker()
and bypass the permission model. Therefore, if your use case is to guarantee a malicious package won't be able to perform those operations, --allow-inpector
won't work for you.
However, I think might be possible to restrict what the inspector can do (even through the API) and take into consideration all the limitations imposed by the permission model. I'm not sure about it, I'll need to investigate.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Version
v20.3.1
Platform
No response
Subsystem
Permission
What steps will reproduce the bug?
No response
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
No response
What do you see instead?
node: bad option: --allow-inspector
Additional information
I saw that in @RafaelGSS commit #3df13d5a79 an access control was implemented for inspection mode
I found this comment in his code:
"Without this check, to use the permission model with workers (--allow-worker) one would need to pass --allow-inspector as well"
but the --allow-inspector flag mentioned in this comment is not working.
Is there any way allow inspection mode or is this flag not created yet?