Mercury Layer Vulnerability Disclosures Report \ stacker news ~bitcoin

pull down to refresh

Mercury Layer Vulnerability Disclosures Report conduition.io/code/mercury-disclosure/

1492 sats \ 17 comments \ @conduition 7 Sep bitcoin

This is my report on the technical details of the Mercury Layer vulnerabilities I responsibly disclosed to their developers. I disclosed this report to mercury 4 days ago. Earlier today, the mercury devs released a patch to address these vulnerabilities (without my review). I haven't reviewed their code yet to see if the fixes are effective, or if they've introduced any regressions.

I have more to say about the subjective experience of finding and disclosing these vulnerabilities but i'm out of energy today. I'll comment on this post once I have the time and energy to write.

view all related items

190 sats \ 13 replies \ @theariard 7 Sep

@conduition sorry you let 4 days between initial report to vendors and full disclosure ???

like did the Mercury vendors physically threaten you or committed any other ethically dubious behaviors before to act so ???

21 sats \ 7 replies \ @supertestnet 7 Sep

It's not a big deal with Mercury because it's testnet only

Responsible disclosure is more relaxed when all the money involved is fake

0 sats \ 1 reply \ @ek 7 Sep

Hopefully by the time you’re reading this report, these vulnerabilities have already been fixed and aren’t deployed in any production systems handling real money.

@conduition isn't even sure themselves. This disclosure doesn't look good.

43 sats \ 0 replies \ @conduition OP 8 Sep

Well, due to the nature of mercury, it's impossible to know. The key server is a blind-signer which is agnostic to whether its users are on testnet, mainnet, signet, etc.

The vulns themselves are in the client code, and mercury has no insight as to who (if anyone) is running that code, or what networks they're running on. No way to notify them besides publishing.

0 sats \ 4 replies \ @theariard 7 Sep

From a quick read of Mercury server code, there is support for mainnet: https://github.com/commerceblock/mercurylayer/blob/dev/server/src/server_config.rs#L98

From protocol documentation (https://github.com/commerceblock/mercurylayer/blob/dev/docs/protocol.md#initialisation) the coin pubkey is a key-path spend to P (P1 = O1 + S1). If the statecoin is spent as a happy path, there shall be no mark in the blockchain logs.

So how can you be sure there is no mainnet traffic ?

200 sats \ 2 replies \ @supertestnet 7 Sep

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:

"there were no mainnet users, so no funds were at risk" source

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.

21 sats \ 0 replies \ @conduition OP 8 Sep

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

0 sats \ 0 replies \ @theariard 7 Sep

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...

0 sats \ 0 replies \ @tptrevethan 7 Sep

We are not aware of anyone else using the code or deploying a server.

The nature of blinded server means that we can't tell if it's being used for mainnet or testnet, but we run two public servers: One 'test' server that isn't secured and gets restarted regularly, and is free to use - we are clear in our docs that no-one should use this server for real money. This gets quite a bit of use.

We also run a 'production' server that is deployed using secured and replicated bare metal hardware - this currently requires a LN fee to use. We were considering this 'production ready' for an app that is being worked on, but it has not been advertised for public use.

So far, the only use of this server has been us testing it - so I believe we can be very confident that there were no user funds at risk.

0 sats \ 2 replies \ @conduition OP 8 Sep

xD no no no, @tptrevethan and I had a very reasonable discussion of how to handle this and roll out fixes. I offered to give Mercury as much time as they needed to roll out fixes, but then Mercury went ahead and published the vulnerability report on Twitter. Only after seeing that did I publish it to my blog as well. The cat was already out of the bag at that point.

200 sats \ 1 reply \ @theariard 9 Sep

@conduition Thanks for the clarification.

Look, one piece of advice if a vulnerability report is to be quite clear in giving a disclosure timeline ahead (and fair to update in flight if they are mitigations developed and deployed). If the report is done outside of a bug bounty program with no rules of engagement, picking up a timeline is really on your shoulders. In the situation of very low funds exposed, as apparently it’s the case here, giving 2 weeks of warn-up would have been very good courtesy. My IMHO only.

0 sats \ 0 replies \ @conduition OP 3 Oct

Thanks and good point. I'm new to this and wasn't expecting mercury to unilaterally publish without asking me first. My mistake was in not being explicit about timeline with them, and also Tom admitted that he thought my vulnerability report (given over a private link to my website) was publicly accessible on my blog (it wasn't). That's why mercury rushed to publish fixes ASAP.

Miscommunication all around and a good learning experience for next time in a low-stakes environment

0 sats \ 0 replies \ @tptrevethan 7 Sep

Also, it seems we published the link to the report on twitter, before he linked it on his homepage in here.

0 sats \ 0 replies \ @tptrevethan 7 Sep

Just to clarify - the report was shared with us via a link to a document which was public accessible, but I don't think was linked from his homepage.

Also this was only shared after an initial discussion where we stated there were no mainnet users, and so it was very unlikely any funds were at risk.