x/vulndb: potential Go vuln in code.vegaprotocol.io/vega: GHSA-8rc9-vxjh-qjf2

[GoVulnBot]

In GitHub Security Advisory GHSA-8rc9-vxjh-qjf2, there is a vulnerability in the following Go packages or modules:

Unit	Fixed	Vulnerable Ranges
code.vegaprotocol.io/vega	0.71.6	< 0.71.6

Cross references:
No existing reports found with this module or alias.

See doc/triage.md for instructions on how to triage this report.

modules:
    - module: code.vegaprotocol.io/vega
      versions:
        - fixed: 0.71.6
      packages:
        - package: code.vegaprotocol.io/vega
summary: 'Vega''s validators able to submit duplicate transactions '
description: |
    A vulnerability exists that allows a malicious validator to trick the Vega network into re-processing past Ethereum events from Vega’s Ethereum bridge. For example, a deposit to the collateral bridge for 100USDT that credits a party’s general account on Vega, can be re-processed 50 times resulting in 5000USDT in that party’s general account. This is without depositing any more than the original 100USDT on the bridge.

    Despite this exploit requiring access to a validator's Vega key, a validator key can be obtained at the small cost of 3000VEGA, the amount needed to announce a new node onto the network.

    The steps to carry out this exploit are as follows:
    1. Cause an Ethereum event on one of the bridge contracts e.g a deposit to the collateral bridge, or the staking bridge
    2. This will result in the Ethereum-event-forwarder of each node to submit a ChainEvent transaction to the Vega network corresponding to that event
    3. Scrape the valid chain event transaction from the Tendermint block data using a node’s Tendermint API
    4. Change the value of the `txId` field of the ChainEvent to any valid, but different, value
    5. Bundle the tweaked ChainEvent into a new transaction, sign it with a validator key and resubmit to the Vega network
    6. The fraudulent ChainEvent will be processed by Vega as if it were a new ChainEvent even though it did not occur on Ethereum

    The key to this exploit is in step 4. The `txId` field of the ChainEvent is used when checking for ChainEvent resubmission, but NOT during the subsequent on-chain verification of the event. Therefore changing the `txId` of an existing ChainEvent is enough to by-pass the duplication check and for it to still be verified as a real event.

    ### Impact
    The impact of this exploit is dependent on the ChainEvent being manipulated. The below table describes each one:

    | Chain Event  | Allows | Consequence |
    | ------------- | ------------- | ------------- |
    | Deposit | Generation of unlimited funds of any asset  | Withdrawal of all assets |
    | Stake Deposit  | Delegate unlimited Vega to a single node  | A single node has controlling amount of voting power  |
    | Stake Removed  | Force a Validator node to drop below self-stake requirements  | Prevents reward payouts  |
    | Bridge Stop  | The Vega network to think the bridge is stopped  | Prevent anyone from withdrawing funds  |
    | Signer Removed  | The Vega network to think a validator nodes is not on the multisig contract  | Prevent reward payouts  |

    ### Patches
    v0.71.6

    ### Workarounds
    No work around known, however there are mitigations in place should this vulnerability be exploited:

    - there are monitoring alerts, for `mainnet1`, in place to identify any issues of this nature including this vulnerability being exploited
    - the validators have the ability to stop the bridge thus stopping any withdrawals should this vulnerability be exploited

    ### References
    N/A
cves:
    - CVE-2023-35163
ghsas:
    - GHSA-8rc9-vxjh-qjf2
references:
    - advisory: https://github.com/vegaprotocol/vega/security/advisories/GHSA-8rc9-vxjh-qjf2
    - fix: https://github.com/vegaprotocol/vega/commit/56b09bf57af8cd9eca5996252d86f469a3e34c68
    - web: https://github.com/vegaprotocol/vega/releases/tag/v0.71.6
    - advisory: https://github.com/advisories/GHSA-8rc9-vxjh-qjf2

[zpavlinovic]

Binary. The fix is in the packages not imported by anyone.

[gopherbot]

Change https://go.dev/cl/504857 mentions this issue: data/excluded: add GO-2023-1865.yaml

[gopherbot]

Change https://go.dev/cl/592761 mentions this issue: data/reports: unexclude 75 reports

[gopherbot]

Change https://go.dev/cl/606787 mentions this issue: data/reports: unexclude 20 reports (7)