Skip to content
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

proto: fix uint64->int overflow in table unmarshal #461

Merged
merged 3 commits into from
Nov 29, 2017
Merged

Conversation

neild
Copy link
Contributor

@neild neild commented Nov 29, 2017

No description provided.

@neild neild requested a review from dsnet November 29, 2017 21:44
@@ -1849,7 +1849,7 @@ func findEndGroup(b []byte) (int, int) {
return -1, -1
}
i += k
if i+int(m) > len(b) {
if uint64(len(b)) < uint64(i)+m {
Copy link
Member

@dsnet dsnet Nov 29, 2017

Choose a reason for hiding this comment

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

Can't this still overflow with malicious values of m? E.g., if m was set to math.MaxUint64-i+1, then this check will never trigger.

Since, we know that i ≤ len(b), wouldn't a more safe check be: uint64(len(b)-i) < m since the LHS is guaranteed to be a positive value?

Similarly, we should also protect the WireFixed32 and WireFixed64 cases to be of this form, although it is far less likely those can be exploited.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The i+m operation can wrap, although the harm is limited to misinterpreting the contents of the buffer--it can't panic, because we've ensured that the wrapped i+m is within the bounds of b.

Rewrote it anyway to be more correct. Fixed one other existing case where this could wrap at the same time.

@dsnet dsnet merged commit 1ec9e17 into golang:dev Nov 29, 2017
@golang golang locked and limited conversation to collaborators Jun 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants