200 sats \ 2 replies \ @supertestnet 7 Sep \ parent \ on: Mercury Layer Vulnerability Disclosures Report bitcoin
The server is configured to run on testnet, not mainnet, which is important because the server interacts with the network in order to collect fees. It has support for configuring it to run on mainnet later but it is not set to do so right now.
Client software could ask the testnet server to sign a mainnet tx, and since the server is blind, it wouldn't know the difference, but the Mercury CTO seems confident that no one is doing this yet:
They keep records of signature requests and they can probably see that basically the only people requesting signatures from Mercury's server are their own testers. Certainly there is no publicly released client software configured for mainnet so it's unlikely a significant number of people modified the software to run on mainnet, and if they did, that's on them.
Certainly there is no publicly released client software configured for mainnet
The mercury client code can be configured to use mainnet statecoins by simply setting
network = "bitcoin" in the client's Settings.toml file, so it's not that hard to set up. In fact, to demonstrate the vulns to mercury I double-spent some mainnet coins after ostensibly "transferring" the statecoin UTXO to Tom. But it would take a conscious effort to do that, in spite of blatant warnings to the contrary.Really I have no idea if there are any mainnet users, but I find it unlikely. See tom's post below for more info
reply
Client software could ask the testnet server to sign a mainnet tx, and since the server is blind, it wouldn't know the difference, but the Mercury CTO seems confident that no one is doing this yet:
Sure, if you’re vendor and there are plausible vulnerabilities affecting your soft, this can be very pragmatic to downside funds exposed. Giving time to people to deploy the fixes.
I don’t wish to sound too harsh on conduition here, I believe it’s great to have more folks doing vulnerabilities hunting in the ecosystem. On the other hand, in infosec rule of thumb is often to give 90 days to vendors. Unless there are clear hints that vendors do not wish to implement mitigations (or mitigations cannot be deployed easily).
I know 90 days can be a lot, so even if you think circumstances are worthy of less, in my opinion nothing displayed in the disclosure report warrants to give only 4 days to the vendors.
As of today, it’s indeed quite easy to go and burak a bitcoin L2. But I don’t think it is the culture we wish to nurture on the long-term in the ecosystem, if we wish seriously to take care of end-users financial wealth (or privacy). Failing to do so, that’s only going slowly towards the path were vulnerabilities are weaponized for other purposes...
reply