-
Notifications
You must be signed in to change notification settings - Fork 32
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
Port DOS protections to our protojson fork #143
Conversation
This commit ports over the fixes (and tests) for the two DOS bugs fixed by golang/protobuf recently: 1. golang/protobuf#1583 2. golang/protobuf#1584 These changes come from protocolbuffers/protobuf-go@bfcd647
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.
In a perfect world we'd maintain just a set of patches on top of existing lib, but that is annoying.
var open int | ||
for { | ||
tok, err := d.Read() | ||
if err != nil { | ||
return err | ||
} | ||
|
||
case json.ArrayOpen: | ||
for { | ||
tok, err := d.Peek() | ||
if err != nil { | ||
return err | ||
} | ||
switch tok.Kind() { | ||
case json.ArrayClose: | ||
d.Read() | ||
return nil | ||
default: | ||
// Skip array item. | ||
if err := d.skipJSONValue(); err != nil { | ||
return err | ||
} | ||
switch tok.Kind() { | ||
case json.ObjectClose, json.ArrayClose: | ||
open-- | ||
case json.ObjectOpen, json.ArrayOpen: | ||
open++ | ||
if open > d.opts.RecursionLimit { | ||
return errors.New("exceeded max recursion depth") |
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.
You're not doing recursion anymore, so does it matter to track the depth?
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.
This is copied verbatim from the official codebase
We'd need to fork the whole protobuf stack to do so, which would suck. We could do that and periodically rebase our changes on the upstream, but that's a lot of work |
See temporalio/api-go#143 for details
See temporalio/api-go#143 for details
Bump the version of go-api fix the protojson DOS vulns recently patched in the upstream golang/protobuf. See temporalio/api-go#143 for details
## What was changed I bumped the version of api-go and sdk-go and _slightly_ altered our nettest RPC factory interface to deal with changes in v1.60.0 of go-grpc ## Why? To fix the protojson DOS vulns recently patched in the upstream golang/protobuf. See temporalio/api-go#143 for details ## How did you test it? I pulled the tests added to the protojson repo into our fork ## Potential risks N/A ## Is hotfix candidate? No as it requires all our other proto changes which aren't released
## What was changed I bumped the version of api-go and sdk-go and _slightly_ altered our nettest RPC factory interface to deal with changes in v1.60.0 of go-grpc ## Why? To fix the protojson DOS vulns recently patched in the upstream golang/protobuf. See temporalio/api-go#143 for details ## How did you test it? I pulled the tests added to the protojson repo into our fork ## Potential risks N/A ## Is hotfix candidate? No as it requires all our other proto changes which aren't released
## What was changed I bumped the version of api-go and sdk-go and _slightly_ altered our nettest RPC factory interface to deal with changes in v1.60.0 of go-grpc ## Why? To fix the protojson DOS vulns recently patched in the upstream golang/protobuf. See temporalio/api-go#143 for details ## How did you test it? I pulled the tests added to the protojson repo into our fork ## Potential risks N/A ## Is hotfix candidate? No as it requires all our other proto changes which aren't released
What changed?
I ported over the DOS fixes from the official protobuf repository
Why?
Two DOS bugs were fixed by golang/protobuf recently:
How did you test it?
I ported over their tests for the issue
Potential risks
None,