Security Vulnerability Examples

Available Tooling

Github’s inbuilt tooling for creating security policies and issuing security advisories
https://immunefi.com/hackers/ - placing bounties on finding vulnerabilities

Some crypto project vulnerability processes + bounty information

Paritytech / substrate / frontier
- https://github.com/paritytech/frontier/security/advisories
- https://github.com/paritytech/substrate/security/policy
- https://github.com/paritytech/polkadot/security/policy
  - For medium or high severity security vulnerabilities, please report them by email to [email protected]. If you think your report might be eligible for the Parity Bug Bounty Program, your email should be sent to [email protected]. Please make sure to follow guidelines when reporting.
- https://www.parity.io/bug-bounty/
- https://polkadot.subsquare.io/treasury/child-bounty/32
  - A payout for a bug bounty of $67500 USD using bounty system
- https://polkadot.polkassembly.io/post/915
  - Funding for an audit of the Open Runtime Module Library
Ethereum
- https://github.com/ethereum/go-ethereum/security/advisories

Security Disclosure Policies for some crypto projects:

https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities
- The primary goal for the Geth team is the health of the Ethereum network as a whole, and the decision whether or not to publish details about a serious vulnerability boils down to minimizing the risk and/or impact of discovery and exploitation. At certain times, it’s better to remain silent. This practice is also followed by other projects such as Monero, ZCash and Bitcoin.
- As of November 2020, our policy going forward is:
  - If we silently fix a vulnerability and include the fix in release X, then,
  - After 4-8 weeks, we will disclose that X contained a security-fix.
  - After an additional 4-8 weeks, we will publish the details about the vulnerability.
- A published JSON file containing known vulnerabilities for Ethereum (geth)
  - Extremely well detailed and includes great metadata
  - https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities.json

Issues / Lessons:

Lack of defined process or communication channels for disclosing and/or handling urgent security matters (NOTE: this is not accurate and seems to just reflect poor information flow within the Polkadot ecosystem)
- Currently, as I’m writing this post, there are some security vulnerabilities in Substrate that could be abused on some Parachains but have not been disclosed by Parity. I suppose they want to have it fixed/deployed in the relaychain before revealing them but I think it is a bad strategy for the ecosystem.
- I would also add that as a founder/lead on one of the parachains that may be affected by this, I have not received any responsible disclosure on this alleged vulnerability. That also seems very odd to me.
- https://forum.polkadot.network/t/improving-the-substrate-ecosystem-vulnerabilities-disclosure/38
Indecision regarding ownership of, or financing audits of pallets between different parties:
- In addition to the difficulty to maintain it, Parity’s (to my understanding) doesn’t want to take any responsibility for Frontier’s pallet/code/issues, making it hard to guarantee its quality and support. (The Moonbeam foundation is currently the one paying for audits in the Frontier/EVM repos)
- We’ve been contributing to Frontier for a couple of years now and I think Wei has done great designing and reviewing the project proposals but Alan is right in that a single maintainer can sometimes drag reviewing process depending on that person’s schedule, which is totally fine, but can be simply solved by having more eyes on it.
- https://forum.polkadot.network/t/making-frontier-a-first-class-citizen/37