-
Notifications
You must be signed in to change notification settings - Fork 3.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
refactor(x/tx/decode): bulletproof against protowire.ConsumeTag potential varint overflows #18611
refactor(x/tx/decode): bulletproof against protowire.ConsumeTag potential varint overflows #18611
Conversation
This change adds extra validation against varint decoding to ensure that rejectNonADR027TxRaw doesn't panic when we try to slice txBytes[m:] due to the fact that varint decoding can be trivially fooled by adding extraneous bytes peppered with 0x80, as investigated at https://cyber.orijtech.com/advisory/varint-decode-limitless
WalkthroughWalkthroughThe update involves adding a validation check to a function that decodes transaction bytes. This check ensures that the length of the decoded transaction does not surpass the actual byte length of the input. Additionally, a comment has been added to highlight potential issues with the decoding of variable-length integers (varints). Changes
TipsChat with CodeRabbit Bot (
|
@elias-orijtech could you please examine staticmajor to see what it is consistently failing on all the PRs for this repository. |
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.
Maybe we should add a test? LGTM.
Thanks for the reviews @julienrbrt and @testinginprod! @testinginprod the test is quite complex to produce the exact byte pattern and I have a fuzzer running currently for protowire that'll exhaust the path and when I do some attacks on that repository. My change is pre-emptive protection for the cosmos-sdk as varint decoding is fickle for most implementations. |
This change adds extra validation against varint decoding to ensure that rejectNonADR027TxRaw doesn't panic when we try to slice txBytes[m:] due to the fact that varint decoding can be trivially fooled by adding extraneous bytes peppered with 0x80, as investigated at https://cyber.orijtech.com/advisory/varint-decode-limitless
/cc @elias-orijtech
Summary by CodeRabbit