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

RLP list decoding too lax for objects #255

Open
kdeme opened this issue Jun 18, 2020 · 1 comment
Open

RLP list decoding too lax for objects #255

kdeme opened this issue Jun 18, 2020 · 1 comment
Labels
discoveryv5 Discovery v5 related issues rlp

Comments

@kdeme
Copy link
Contributor

kdeme commented Jun 18, 2020

There seems to be no list size check done when decoding an object (possible also in general for lists?).

e.g. when decoding ef8c000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000080 to a WhoAreYouObj, that works as expected, as the rlp is valid.

However, decoding c08c000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000080 to a WhoAreYouObj, also works, while clearly the list size (c0 -> size 0) is not correct.

Only spotted this by adding a re-encode step and comparing with original payload in a fuzzing test.

Perhaps related with #254

@kdeme kdeme added rlp discoveryv5 Discovery v5 related issues labels Jul 8, 2020
@mjfh
Copy link
Contributor

mjfh commented Feb 21, 2022

Just ran into that issue when debugging wire protocol datagrams as processed by checkedRlpRead(). In particular, r.read(MsgType) succeeds when r is a non-empty list and MsgType is EmptyList and also when r is a list of more than one element and MsgType is DisconnectionReasonList, a single element object. The latter one coincides with the reported issue, above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discoveryv5 Discovery v5 related issues rlp
Projects
None yet
Development

No branches or pull requests

2 participants