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
Because many contract authorise by verifying msg.sender, call any interface of any target contract will make the Port (and ORMP) being able to used by anyone as caller, and developer is very difficult to find all the contracts which granted configs and special auths to the Port (and ORMP), this addresses need to be put in the target/callee blacklist.
Adoption EIP165 Interface Detection will be a safer and easier solution although it may introduce some incompatibility in Application and message encoding(no interface sig needed)
The text was updated successfully, but these errors were encountered:
hackfisher
changed the title
Considering using EIP165 Interface Detection instead of call any interface of any target contract
Considering using EIP165 Interface Detection instead of call any interface of any target contract in V3
Jun 3, 2024
The V2 version also has the possibility of front-running, which is possible if an attacker performs a setAppConfig operation on a newly deployed ORMP protocol before the ORMP-U port is upgraded.
https://github.com/msgport/msgport/blob/54a9bfd95694d2ebef61ef7f2ef3f0303818876f/src/ports/base/BaseMessagePort.sol#L47
Because many contract authorise by verifying msg.sender, call any interface of any target contract will make the Port (and ORMP) being able to used by anyone as caller, and developer is very difficult to find all the contracts which granted configs and special auths to the Port (and ORMP), this addresses need to be put in the target/callee blacklist.
Adoption EIP165 Interface Detection will be a safer and easier solution although it may introduce some incompatibility in Application and message encoding(no interface sig needed)
The text was updated successfully, but these errors were encountered: