Repository navigation
Security Issues of the Mithril Software Architecture #1487
Description
Why
The current Mithril network architecture is susceptible to various types of denial-of-sevice attacks of the block producer nodes that run the Mithril signer. The goal of the Mithril network project to interact with the stake weighted majority of block producers makes this an even more pressing issue. The close interaction of the Mithril signer with the cardano-node database and the access to secret keys and certificates as outlined in the Architecture overview creates a myriad of security issues.
The design decision that a single server, the Mithril aggregator, is interacting with the most important Cardano nodes on the network, the stake-weighted majority of the block producers, is a huge security risk. Even an inadvert bug in the Mithril software could disrupt the majority of the block producers and lead to a catastrophic network failiure of the Cardano network.
Having such a single point of failure risk on the Cardano network is not acceptable.
It also puts an enormous trust burdon on a piece of software that is maintained outside of the main cardano-node repository.
What
A reasonable approach to mitigate the main security issues above is to integrate the Mithril signer code into the cardano-node software and use the establisched networking infrastructure to relay the required Mithril information over the Cardano P2P network. The Mithril aggregator can then listen for specific Mithril messages on the Cardano P2P network without the need to penetrate the firewalls and infrastructure of the stake pool operators.
Activity
onyxstakepool commentedon Feb 6, 2024
@abailly-iohk Thanks for your respone.
After learning in the Discord Moria channel that it is not technically necessary to run the Mithril signer on a block producer, I am much less concerned now about the security implications. Since a simple relay server is also sufficient for the Mithril signer only the KES key and the node certificate are at risk. Even if these two pieces are leaked from the relay, an attacker would not be able to replicate the block producer since the vrf key is still missing. The KES key and the node certificate can be quickly rotated without any harm to the real block producer.
With this understanding, I suggest that the Mithril documentation is changed to recommend the naive deployment also for mainnet. See: Mithril signer deployment model
My original security concern was that an attacker would spend considerable efforts to compromise the Mithril repository and thus gain access to the block producers and wreck havoc on the whole Cardano network.
jpraynaud commentedon Feb 6, 2024
@onyxstakepool Thanks for this issue.
Indeed, the new deployment model has been jointly designed with pioneer SPOs input and feedback, and they raised concerns about having the KES keys exposed on a relay. Prior to the
mainnetlaunch, in late June 2023, we have started rolling out this new deployment (as announced in this dev blog post: https://mithril.network/doc/dev-blog/2023/06/28/signer-deployment-models).As @abailly-iohk already mentioned, we are currently working on a threat model for the Mithril network. This will help us get a better picture of the security related issues, and it will also be an opportunity for the community to contribute and give some feedback.
In the mean time, feel free to share any specific attack scenario that you would already have in mind 👍
Issue #1488 has also been created to make the architecture diagrams easier to understand.
reqlez commentedon Feb 10, 2024
Indeed, it was decided that keeping keys on world-facing cardano-node relays was not very acceptable. However, I don't see how an outgoing connection from a mithril-signer to an aggregator is a huge risk, personally.
In my mind, it's no different than you trusting the NTP client app to connect to an NTP server and not "get hacked" in the process.
"creates a myriad of security issues" I would like to see some example attack scenarios if i'm to be convinced. The way I see it, an attack would have to involve the mithril signer software having a serious bug PLUS the aggregator getting hacked at same time, crafting a malicious response to the signer, that could potentially execute some code in some "buffer overflow, etc". I guess theoretically possible? I think the engineers would have a better idea how possible it is to execute something like this.
RE supply chain attacks, no different than people using any of the add-on software that SPOs use. Like... Koios Tools, Scripts, cncli, etc etc. Not to mention, the operating system where you are running your software from, and the huge number of libraries, packages, etc, not having a supply chain attack.
Don't get me wrong, I do support the idea of Mithril just being integrated into the core protocol, but maybe it's a bit too early for this?
onyxstakepool commentedon Mar 21, 2024
@disassembler just pointed out security issues with squid in the Mithril channel.
https://www.cvedetails.com/vulnerability-list/vendor_id-9950/product_id-17766/Squid-cache-Squid.html
onyxstakepool commentedon Mar 21, 2024
@abailly-iohk Thanks for addressing all the concerns above.
Let me explain here why I keep voicing concerns about how Mithril is set up.
First, as soon as you open a door (port) to your server, you are in the business of defending this door. So, for critical infrastructure you just do not open these doors unless absolutely necessary.
For the cardano-node I am quite confident that every bit that flows in and out of the server is meticulously processed and checked.
For the Mithril signer, relay, and aggregator the whole security concept looks much more ad hoc.
So, I must put a lot of trust into all these additional software pieces. What happens if the aggregator gets compromised or gets seized by the authorities? Then the aggregator software can be manipulated and potentially corrupt the signers and block producers of the stake majority or corrupt the databases of relay servers or even leak keys and so forth.
You might still think this is all moot. Here is a story:
In the early days of Bitcoin there was an IRC client build-in for bootstrapping the network. It took only 4 lines of obfuscated source code to subvert the IRC client to execute arbitrary system commands on the node server. Security analysis showed that this was the downfall of one of the largest crypto exchanges at the time. All wallet keys were leaked. Thereafter all the IRC code was removed from the Bitcoin client.
Now we have the same pattern with Mithril. An unchecked http channel deep into the core SPO infrastructure that sends data back and forth waiting to be exploited.
This is why I am concerned. Also, in the future there might be more than one aggregator with more delegated trust. The risks are just increasing.
ch1bo commentedon Mar 22, 2024
Should we move this discussion maybe to a github security advisory? The same people could be involved, but it would follow our Security guideline and we can still publish the outcome (a fix, change in practice, improved documentation, ...) as a definitive advisory.