pull down to refresh
190 sats \ 13 replies \ @theariard 7 Sep \ on: Mercury Layer Vulnerability Disclosures Report bitcoin
@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 ???
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
reply
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.
reply
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.
reply
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 ?
reply
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.
reply
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
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.
reply
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.
reply
@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.
reply
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
reply
Also, it seems we published the link to the report on twitter, before he linked it on his homepage in here.
reply
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.
reply