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

Not checking the recipient address in channel closing function and updateTransfer function in NettingChannelLibrary.sol file #601

Closed
trivikramak opened this issue May 18, 2017 · 1 comment · Fixed by #602

Comments

@trivikramak
Copy link

Problem Definition

As far as I understood the smart contract code, when closing a channel between two participants, the closer submits the latest known transfer of the counterparty. nonce, transferred_amount and locksroot of the counterparty are updated by decoding the transfer message.

Shouldn't there be a check to see if the recipient of the transfer message is the closer ? I think a potential attack is possible by submitting a transfer message sent by the counterparty to some other person (just making sure that the nonce is valid and appropriate). Same thing is possible with the updateTransfer function.

Am I missing something in this logic ?

Solution

Just add another check to see if the closer is the recipient of the transfer message.

Tasklist

  1. Update decodeTransfer functions to extract recipient information as well
  2. Add a conditional to check if the closer is the recipient of the transfer message in UpdateTransfer and Close functions
@LefterisJP
Copy link
Contributor

Hello @trivikrama619.

You are absolutely correct. There should be a recipient check in the netting channel smart contract as the attacker could eavesdrop on a another channel with the same sender and use their transfer.

Very nice catch!

We will address very soon.

hackaugusto pushed a commit to hackaugusto/raiden that referenced this issue Dec 5, 2019
The MS/PFS iterates through all available servers and join all PFS/MS rooms.
If no rooms are found, it creates them.
Fixes raiden-network#600, raiden-network#601.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants