O1 Labs
O1 Labs looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.
The table below provides guidance on reward sizes for each vulnerability level. The judges assigned by O1Labs Foundation determine the vulnerability level of a discovered vulnerability based on various factors such as the attack area, likelihood and impact.
| Critical (9.0 - 10.0) | High (7.0 - 8.9) | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |
| ------------- | ------------- | ------------- | ------------- |
| $10,000 | $5,000 | $2,000 | $500 |
O1 Labs will make a best effort to meet the following SLAs for hackers participating in our program:
| Type of Response | SLA in business days |
| ------------- | ------------- |
| First Response | 5 days |
| Time to Triage | 10 days |
| Time to Bounty | 10 days |
| Time to Resolution | depends on severity and complexity |
We’ll try to keep you informed about our progress throughout the process.
As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
Follow HackerOne's disclosure guidelines.
Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
In the event that we get multiple vulnerability reports on the same issue, the first report which contains comprehensive information and detailed instructions for replicating the problem will receive the reward. * * Judges reserve the right to reward subsequent submissions.
Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
Social engineering (e.g. phishing, vishing, smishing) is prohibited.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.
You can fork a private chain to find bugs – please do not attack the Mina Bug Bounty Network or Adversarial Network before obtaining prior permission from us.
Employees of O(1) Labs, people paid by the Mina project, and those who work with the codebase as professional Mina developers are ineligible for rewards.
For more questions on our program rules, please join our Discord server to ask any questions you might have.
NOTE: We are running two networks right now: Adversarial Network and Bug Bounty Network. You are encouraged to connect to our Bug Bounty Network, which is specifically set up for the purpose of our Bug Bounty Program.
If you’d like to set up a multi-node Mina network on your own machine, visit the following instructions page.
https://www.notion.so/minaprotocol/Bug-bounty-network-and-local-testnets-98b404872e0c48bcbd136036ad03f1cb
If you’d like to join our Bug Bounty network, you can use the same document to run a node in our network:
https://www.notion.so/minaprotocol/Bug-bounty-network-and-local-testnets-98b404872e0c48bcbd136036ad03f1cb
There is currently a vulnerability (detailed below) that allows an adversary node to force other nodes to exhibit behavior which looks (to network administrators and tools) like a port scan or other kind of network probing attack. If you are going to run our software in a datacenter or cloud environment, and do not want to risk this attack being executed against you (which could result in an angry letter from the cloud or datacenter provider), we recommend the following firewall rules to mitigate the issue until this bug is patched.
-ufw allow 22
-ufw allow 80
-ufw allow 443
-ufw enable
-ufw deny out from any to 10.0.0.0/8
-ufw deny out from any to 172.16.0.0/12
-ufw deny out from any to 192.168.0.0/16
-ufw deny out from any to 100.64.0.0/10
-ufw deny out from any to 198.18.0.0/15
-ufw deny out from any to 169.254.0.0/16
If you have any questions or need support in setting up your network, join our Discord Community. You can join the #bug-bounty-network channel to discuss anything related to our Bug Bounty Program.
O1 Labs looks forward to working with the security community to find security vulnerabilities in order to keep our protocol safe and secure.
Our code lives on Github, and can be investigated here: https://github.com/MinaProtocol/mina
To best understand how to get started on Mina, documentation can be found here: https://minaprotocol.com/docs
In PoW protocols, all you need to arrive at consensus is the longest chain rule - you choose the chain with the highest hash power in it. Such a simple rule by itself will not work for PoS systems, because PoS systems suffer from the vulnerability of so-called “nothing at stake”. This means that, unlike a PoW system, it costs almost nothing to participate in multiple chains at the same time. This vulnerability potentially allows for special attacks called long-range attacks, where an adversary can create a fork and over time try to adversarially increase the stake participation in the adversarial chain; one example of that attack approach is to cheaply buy discarded keys and sign blocks with those keys in the past. While nodes that have been active can see through the attack, newly joining nodes or the nodes that were inactive for some time could fall for the attack and choose the adversarial chain if they apply the longest chain rule.
There are many bandaid solutions to this problem, such as having a trusted central entity to advise on the active chain to such nodes or slashing. Instead, the consensus protocol Ouroboros Samasika, by design, solves this problem. It has a special chain selection rule whenever the forks are too long. The idea is the following: After creating the fork, the adversary would have slowly strengthened the adversarial chain. Instead of comparing the chains at a point where the adversarial chain has been well strengthened, we compare the chains at a point after the fork but before the adversary has even had a chance to strengthen it. This allows us to choose the right chain, thereby overcoming the nothing-at-stake challenges.
It is possible to submit invalid proofs and let the block producer attempt to verify them. Mina Protocol doesn’t currently have a mechanism to blacklist hosts/identify senders who are sending invalid proofs so we cannot stop them.
If an adversarial node sends a transaction with a really low fee then follows it up with a large number of reasonable fee transactions then it can be possible to cause the pool to fill to capacity and eject the low fee transaction along with all the others, resulting in dropped transactions and causing nodes to become out of sync.
Transactions with expiration times do not get properly evicted from the transaction pool when they can no longer be applied to the chain. If an adversarial node sends a series of transactions with expiration that expire before they are included, they can fill up the transaction pool with their inapplicable transactions, effectively denying valid transactions from being submitted to nodes in this state.
It is possible to bundle invalid snark work in a snark pool diff and have nodes on the network you broadcast it to verify it. This will not only result in waste of time on the snark that you have sent, but it also causes the node to redo more expensive verification on additional snarks that it is processing at the same time. If this happens in a distributed and targeted fashion, you can easily DDoS a node. However a mechanism for verifying work more quickly is in development.
It is possible for a node with a significant (estimated ~25%, but non-honest-participation-assumption breaking) amount of stake to trick new nodes that come online into syncing to a side chain. This works so long as the bootstrapping node does not hear any of the honest chain’s blocks before bootstrap is completed, and if the side chain is > k in length off of the honest chain, but < 2*k+delta behind the honest best tip.
This trick doesn’t permanently convince the node that the side chain is valid, but until the difference between the side chain and the honest chain is > 2*k+delta, the tricked node would believe the adversarial side chain state instead of the honest chain state.
This approach can be used to convince users that they have been sent money that they didn’t actually receive, or cause users to send transactions on the fake state, while forwarding those transactions to the real chain. For instance, an adversary could “pretend” to send a token to an honest node in exchange for another token, and the honest node could see the fake network state and believe that the adversary had actually sent them tokens. When the honest node broadcasts the transaction to send money back to the adversary, that transaction goes into the real chain, even though the honest node didn’t receive the tokens from the adversary in the real chain.
In practice, you would peer to a few “known responsible” independent parties initially
It is possible for a bootstrapping node to be tricked into throwing out its locally persisted transition frontier and epoch ledgers if it can initially be convinced of an invalid side chain during bootstrap.
This vulnerability, in conjunction with a network wide crash, could be used to make the network unbootable (crash all the nodes, when they come online, trick them into throwing out their persisted chain states). In this state, the network would be recoverable via archived data.
We are aware that our libp2p has some bugs and vulnerabilities and are currently working towards resolving those issues.
The libp2p max message size is not checked when deserializing streams of data. The size of messages we are deserializing has no maximum size enforcement. If an adversary attempts to send a message which (in the serialization format) states it has a very large size, the deserialization will attempt to overread the incoming message, resulting in a crash.
Serving local ip addresses to other nodes as peers can result in causing other nodes on the network to attempt to contact local ip addresses on their network. This can be utilized to make it look like another node on the network is performing a port scan of whatever local network it is running on. This will be flagged by datacenter/cloud providers, potentially resulting in the node being shutdown and the owner of the account to be banned from using the service.
Additional Information:
Any activity which may lower the chain quality (min_window_density) of the chain the network converges on would reduce the honest stake assumption required to perform a long fork attack against our blockchain. We want to discover any behavior which can trigger a reduction in the density of blocks produced on the main chain of the network.
Additional Information:
Our honest stake assumption with our current parameters is 65%, so an adversary needs >35% of the network’s supply in order to break that assumption and execute attacks which manipulate the chain. Exempting the above chain quality attack, we want to find any activity which may lower the honest stake assumption, including (but not limited to): temporary manipulatable network partitions, block production/receipt denials, and gossip network inconsistencies.
Additional Information:
Exempting the aforementioned bootstrap denial method using retargeting, any additional methods to deny or delay the bootstrapping process for honest nodes is considered a vulnerability to the protocol (due to assumption in the consensus paper).
Additional Information:
We’d like to discover any ways in which a node can manipulate the selection of transactions/snark work for inclusion in blocks in a way where the block producer is not making choices that are in their economic incentive. As an example of this kind of an attack: “there is a way to make a block producer select a piece of snark work you created over another piece of work which would have cost less to a block producer”.
We have provided a list of areas of possible interest and value for the security community to discover vulnerabilities in. We hope this provides some direction but the list is not restricted – if you discover vulnerabilities beyond these areas, we will evaluate them.
Additional Information:
Given the severity of DDoS attacks, we’d only like for you to describe the (theoretical) way/scenario in which such an attack could happen. Once the O(1) Labs engineering team reviews your submission, we might invite you to try to attack the network in actuality – please wait for permission from us prior to attack of the network.
Additional Information:
We’d like to avoid instances in which an adversary could fool a bootstrapping node to bootstrap to a malicious chain, and not the main chain. We’d also like to make sure that an adversary is not able to cause a synchronized node to enter bootstrap by sending it messages as opposed to eclipsing it and waiting for time to pass.
Additional Information:
We’d like to discover instances in which an adversary could separate a node from the rest of the network or could trick a node into thinking that a handful of nodes are a good representation of the network when they’re really not.
Additional Information:
We're interested in vulnerabilities that could result in consensus attacks. These could take on several forms, including:
Forcing a reorganization of the chain. For example, If an attacker can manipulate consensus to the point where you can control what block is included in the longest chain, it'll be a consensus attack.
Performing a long fork.
Causing reorgs to happen at length greater than k. Causing a reorg with longer than k blocks could indicate a problem with the network.
Manipulating the epoch seed. This would be a major attack as if an adversary could use it to give themselves good vrf distribution so they win more.
Additional Information:
We want to make sure that the network is resilient against corrupt messages. For example:
We want to guard against attacks in which, for example, an adversary sends to the network a “garbage” message that’s several bytes-long and the network tries to read it.
Similar to the Message Length Attack, we want to make sure that we’re resilient to corrupt RPC messages (where these messages contain garbage data). It’s important to protect against these as they might cause a crash and be a denial of service.
Additional Information:
Slow loris attacks can overwhelm targeted severs by opening multiple connections between the attacker and the target. We currently use Libp2p which provides some protection against this, but we’d like to discover vulnerabilities that can allow these attacks.
Additional Information:
We want to ensure that invalid transactions are denied by the network. Mina has two different paths for transaction logic – a circuit representation in the snark and validation out of the snark. We want to find any vulnerability that could cause a transaction to be valid out of the snark but invalid in the snark.
Additional Information:
Because consensus outside the snark is slightly different from consensus in the snark, we’re interested in ways people could exploit this to produce invalid blocks.
Additional Information:
We’d like to discover any attack vectors that could involve censoring or manipulating the mempools by taking advantage of our selection rules, spamming invalid info (especially snarks), censoring rebroadcasts.
Additional Information:
We’d like to discover any methods where a forged or corrupted network message can crash a node and the scale at which this can impact the network.
Additional Information:
We’d like to identify if there are any vulnerabilities in the daemon that would allow a remote attacker to access or execute on the target machine.
Additional Information:
If there are two block producers with the same key that produce two different blocks, we would like to know if this exploit can be used to break consensus or cause a fork.
Additional Information:
We’d like to find any vulnerabilities that exist in our dependencies. We are not up-to-date on the latest version of OCaml, and some of our dependencies are on older versions because of this. It’s possible that there are some known vulnerabilities which have been patched in libraries we depend on, potentially exposing said vulnerabilities in our protocol software.
Additional Information:
Check out our github page for list of known and submitted issues:
https://github.com/MinaProtocol/mina/issues
Anything involving the GraphQL server
Anything related to the O1labs or Mina protocol website
The O1Labs Foundation infrastructure
This policy crawled by Onyphe on the 2021-03-29 is sorted as bounty.
FireBounty © 2015-2024
