Poly Bridge Cross-Chain Security Reinforcement Solution
After analysing the Exploit as explained in the previous blog The Poly Network Exploit Analysis, we have conducted a review on our bridge security solution with extra reinforcement planned and implemented.
The solution to avoid the attack
The Exploit was completed via implanting virus in programs jointly run by multi-parties of the bridge. The exposed vulnerability is that the programs are compiled in a single place and then distributed to the other parties. Thus, we changed the way to compile and distribute softwares. Solution details include:
- Add auditing of the access of the source code with fine-grained access controls on all the relevant repositories.
- Every party should compile the programs by themselves, and compare the hashes of the generated binaries with other parties before spawning processes. To achieve this, we started to use containers for the compile process to ensure parties share the almost same compile environment.
- The access to the machines used to compile programs should be well audited and the machines should be isolated from other purpose usage.
Poly Bridge cross-chain transaction flow
The normal process of Poly Bridge cross-chain transactions is as follows:
- Users lock their assets in the original chain to initiate cross chain transactions.
- Cross-chain transaction events are submitted to the Poly relay chain for processing with a cross-chain proof generated in the relay chain.
- Poly cross-chain proof is submitted to the target chain to unlock the corresponding amount of assets.
Current bridge security solutions
Currently we implemented a monitoring of the bridge system to detect suspicious transactions. This monitoring will trigger the pause of the contracts when necessary to avoid loss of assets. Specifically:
- Monitoring software scans all cross-chain transactions in the Poly relay chain and performs original chain verification for each transaction.
- Monitoring software scans all cross-chain transactions in the target chain and performs relay chain verification for each transaction.
- Any illegal transactions will trigger the cross-chain contract shutdown program, temporarily suspending the release of assets on the target chain. Trigger conditions include (any one of the following):
-A hacker directly constructs a transaction on the relay chain that does not exist in the source chain or has inconsistent cross-chain parameters. StorageAt(ID) != Keccak256(MakeTxParam)
-A hacker constructs a transaction on the target chain that does not exist on the relay chain or has inconsistent cross-chain parameters.
Reinforcement solutions planned
The target chain, as the final checkpoint for cross-chain logic, is the primary focus of reinforcement to be planned. The reinforcement plan includes the following:
Set asset value limits
Set the maximum cross-chain amount for each token per transaction, requiring manual approval before asset release if the limit is exceeded.
Add a lock-up period
Set a lock-up period for each cross-chain transaction on the target chain. During this period, the monitoring program verifies the transaction (anomalies trigger the pause of target chain contract). After the lock-up period, users need to actively claim the assets on the target chain.
Set daily limits
Set daily limits for cross-chain contracts based on the currency. Exceeding the limit will suspend the corresponding cross-chain functionality until the next day.
