-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Security: Make isolates resilient in the face of malformed messages #1747
Comments
Added Security label. |
Added Isolates label. |
Added this to the M1 milestone. |
I have added code that makes the VM pass along a trusted size with all messages. Siva, I'm assigning this bug to you now. Can you make the message parsing itself resilient in the face of malformed input? Set owner to @a-siva. |
Added Library-Isolates label. |
Removed Isolates label. |
Added Accepted label. |
Added Library-Isolate label. |
Removed Library-Isolates label. |
Issue #0 has been merged into this issue. cc @kasperl. |
Removed Priority-Medium label. |
Removed this from the M5 milestone. |
Currently there is no functionality to inject messages to the isolate from the outside (through TCP or raw Dart code). The only way is to deliver messages using the C based API and at that point you were already in C. Siva, is there anything for us to do here in the short term? |
It does not seem like we are planning anything in this area. @a-siva please reopen if you think we would work on this. |
If an attacker is able to specify the raw stream of a serialized message (e.g. when a receive port is bound to a tcp port) and the message is read in Snapshot::SetupFromMemory, security problems can occur:
Missing check for length
Potentially missing checks for type (kind) of message (should be restricted to kMessage)
Once first security checks are implemented, the functionality should be fuzzed
If a malformed message is detected, the message potentially can be dropped
Reviewer also suggests this...
Snapshots should be redesigned so that code (type code) and data (type message) are treated differently
...but I'm not sure that this is an issue for us.
The text was updated successfully, but these errors were encountered: