You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Update decodeTransfer functions to extract recipient information as well
Add a conditional to check if the closer is the recipient of the transfer message in UpdateTransfer and Close functions
The text was updated successfully, but these errors were encountered:
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.
The MS/PFS iterates through all available servers and join all PFS/MS rooms.
If no rooms are found, it creates them.
Fixesraiden-network#600, raiden-network#601.
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
The text was updated successfully, but these errors were encountered: