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

fix(protocol): check no loops in multi-hop in Bridge #16659

Merged
merged 8 commits into from
Apr 5, 2024
Merged

Conversation

dantaik
Copy link
Contributor

@dantaik dantaik commented Apr 5, 2024

This PR mitigates the concerns in this issue , but I'm having a hard time to construct an exploiting attack transaction with a bridge loop that has security impact.

@dantaik dantaik marked this pull request as ready for review April 5, 2024 08:29
@dantaik dantaik requested a review from Brechtpd April 5, 2024 08:31
@dantaik dantaik changed the title feat(protocol): checks there is no loop in bridge hops fix(protocol): checks there is no loop in bridge hops Apr 5, 2024
Copy link

openzeppelin-code bot commented Apr 5, 2024

fix(protocol): check no loops in multi-hop in Bridge

Generated at commit: f4906ee6e6ea45db40d1c2ee188ebb69efd23887

🚨 Report Summary

Severity Level Results
Contracts Critical
High
Medium
Low
Note
Total
2
2
0
3
39
46
Dependencies Critical
High
Medium
Low
Note
Total
0
0
0
0
0
0

For more details view the full report in OpenZeppelin Code Inspector

@adaki2004
Copy link
Contributor

Thinking thru, i think it is possible to embeded signals, but i dont think there is a security concern here because of 2 reasons:

  • In order to be malicious you need to somewhat "mock" a call to SignalService on behalf of the Bridge -> otherwise the sendSignal() will use a different slot _sendSignal(msg.sender, _signal, _signal). So you definitely can call SignalService sendSignal, but later during verification the slot is always used with one of the Bridge contracts (so proof will be invalid).
  • For app we always use our own address signalService = resolve(chainId, "signal_service", false);

So given the 2 factors, i dont think a self-referential hop is safety critical.

@dantaik dantaik changed the title fix(protocol): checks there is no loop in bridge hops fix(protocol): check no loops in multi-hop Apr 5, 2024
@dantaik
Copy link
Contributor Author

dantaik commented Apr 5, 2024

Thinking thru, i think it is possible to embeded signals, but i dont think there is a security concern here because of 2 reasons:

  • In order to be malicious you need to somewhat "mock" a call to SignalService on behalf of the Bridge -> otherwise the sendSignal() will use a different slot _sendSignal(msg.sender, _signal, _signal). So you definitely can call SignalService sendSignal, but later during verification the slot is always used with one of the Bridge contracts (so proof will be invalid).
  • For app we always use our own address signalService = resolve(chainId, "signal_service", false);

So given the 2 factors, i dont think a self-referential hop is safety critical.

I tend to agree, but TBH, preventing loops makes me feel more comfortable given the cost is really small.

@dantaik dantaik changed the title fix(protocol): check no loops in multi-hop fix(protocol): check no loops in multi-hop in Bridge Apr 5, 2024
@dantaik dantaik requested a review from adaki2004 April 5, 2024 13:28
@dantaik dantaik enabled auto-merge April 5, 2024 15:01
@dantaik dantaik removed the request for review from davidtaikocha April 5, 2024 15:02
@dantaik dantaik added this pull request to the merge queue Apr 5, 2024
Merged via the queue into main with commit 447cd52 Apr 5, 2024
6 checks passed
@dantaik dantaik deleted the no_bridge_hop_loop branch April 5, 2024 15:03
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 this pull request may close these issues.

3 participants