BUG: Backdoor Execution possible

[abhi3700]

Description

A trusted bridge between 2 contracts (on 2 different chains) could verify & execute an encoded message without it actually been sent from the source chain. For instance, Alice (from Nova) didn't send wTSSC to itself/Bob (on Sepolia), but the receiver (Alice/Bob) received because of Bridge's verification and execution, given the OApp chose the set of malicious DVNs.

One can watch this video 🎬 as a demo to understand.
In the video, the bridge admin (potential hacker) just executed 2 messages without it actually been sent from the source chain.

Old videos to get more context:

• Send tokens from Nova to Sepolia.
• Send tokens from Sepolia to Nova. Add-on

There are 2 repos where u can find the code:

• PR for solidity scripts: Add LZ compatible Wrapped TSSC & Auto Bridge subspace/subspace-evm-contracts#5
• PR for TS scripts: Add LZ compatible Wrapped TSSC & Auto Bridge subspace/layerzero-playground#6

[abhi3700]

Sharing the discussion thread here from LZ team & community:

[abhi3700]

Issue (still open)

"Any malicious bridge pretending to be a genuine, if could somehow (showcasing different packets sending from multiple contracts) get a potential token contract (with high price value) get themselves added into their OApp/OFT/ONFT's DVN Security stack, the project suffers potentially billions of dollars of losses."

Potential solution

"LZ should introduce (sooner) their own LZ token and create kind of blockchain validators-like ecosystem with incentivization. That way it won't be so scattered."

[abhi3700]

Reported to Bug Bounty program as well.

• https://bugs.immunefi.com/dashboard/submission/30670.
• Full report (submitted)

[abhi3700]

Discord chat post Bug Report submission:

Currently, there are 2 main issues/disclaimer for developers using LZ approach as cross-chain solution:

1. LZ is (kind of) centralized with few DVNs available for message verification before its execution.
2. An LZ OApp developer needs to apply due diligence before setting its DVN security stack.

[bholcomb8]

This has been hashed out on discord and is not a vulnerability. Oapp developers must choose the amount of security they want for their use case and pay for said security.