Reading through publications about Web3 security, we’re struck by the same pattern that we’ve seen over and over again: tight focus on blockchain-specific functionality. A lot of useful digital currency, exchange, contract, blockchain, mining, etc., security information and research have been published. But much of that excellent work misses security needs that lie outside the specifics of Web3 and its blockchain, mining, and virtual state machines.
Please consider for a moment all the layers of software between a Solidity contract and the Ethereum Virtual Machine (EVM)’s state machine. Much of that is just “software” not specific Web3 software. For instance, the JavaScript runtime(1) that executes a Solidity smart contract isn’t tied to web3. The REST-ful interfaces at the EVM take web3-specific commands, sure, but REST JSON is implemented through code, maybe open source libraries not tied to particular Web3 problems.
Have there been vulnerabilities in JavaScript runtimes? Absolutely!
Have there been vulnerabilities in JSON implementations? You bet.
Should developers depending on these intermediate parts of the software stack worry? I would!
An example of Smart Contract Development Layers.
Yes, there are Web3-Specific Software Threats
Howard Poston provides a fairly thorough blockchain-specific threat model. The Cloud Security Alliance (CSA) generated a spreadsheet of Web3 exploitation techniques (threats). C4 (Crypto Consortium) offers the Cryptocurrency Security Standard (CCSS). There’s lots more useful Web3 specific security guidance available for the curious: descriptions of smart contract scanners, deep dives into compromises, etc.
Still, we at Resilient Software Security are left wondering where plain old (boring) AppSec/software security comes in? Is the blockchain immune to the plague of vulnerabilities from which every other piece of software suffers? How is that possible? (Hint: it’s not).
The Data Reveals Many Non-Web3 Software Security Issues As Well
CSA compiled a list of publicly available blockchain incidents. Out of 94 total incidents, 26 are attributed to non-Web3 related issues, like application vulnerabilities and cloud tenancy breaches. That is, of the total compiled, just under 30% were issues that vanilla software security normally tries to prevent and/or mitigate.
Out of 94 total blockchain security incidents, 26 are attributed to non-Web3 related issues
As an example of non-Web3 specific issues, the 1st (and reference) Ethereum Virtual Machine (EVM) implementation was written in C/C++, languages well-known for the ease with which memory vulnerabilities slip past scanning tools. Well-funded companies with very mature software security practices and tool sets still release the occasional nasty overflow error. How would the Ethereum programmers escape the same fate? I don’t think they can, assuming that they paid attention to C/C++ secure coding?
Couple the omnipresence of C++ errors to the EVM JSON interfaces and one has created a perfect environment for Remote Code Execution (RCE) compromise. Bear in mind that EVM JSON interfaces must be held in a relatively “open” state since they must be public by necessity. That means that attackers have ample opportunity to probe for opportunities to slip past input validations, if any.
We don’t mean to imply that I have some inside information on EVM issues. Still, there’s a fair chance that somewhere in the C++ EVM waits at least one overflow possibility that can be reached through a crafted bit of JSON data. Why? Because nearly every C++ JSON contains at least one as yet undiscovered remote code execution (RCE).
For another example, smart contracts typically are written in a contract-specific language like Solidity. But Solidity relies upon a software stack that must call JavaScript’s Web3 API. Web3 JavaScript has to execute through a JS interpreter usually written in a lower-level programming language. Some runtimes are written in C/C++ which will include the sorts of software security problems cited above. Which means, buried below Solidity’s careful constructs are the same old software security problems that have dogged our decades in AppSec.
To be fair, the CSA spreadsheet cited above does include some common issues amongst the Web3-specific. The CCSS security standard requires periodic penetration testing, which certainly remains an important piece of the software security puzzle.
Plugging The Gap
Unfortunately, we at Resilient encounter an over-reliance on penetration testing far too often. Penetration tests are a scalpel to catch errors and misses that automated tools can’t find. When performed comprehensively, a penetration test should also be used to prove a system’s threat model. But reliance on penetration testing alone misunderstands its capabilities. Please see our other writing and presentations about the pitfalls of relying solely on penetration tests.
The short of it is, yes, we must pay attention to web3-specific issues. At the same time, all software must also attend to all the tasks required by unexciting but still very necessary, plain old, vanilla, not specifically Web3 software security.
The 5-Minute Security Assessment for Startups
If you are a blockchain startup, founder, or developer, you may have questions about how to properly protect your platform from both web3 and non-web3 security flaws. We're happy to meet and provide advice and recommendations that help you improve... for free.
The best and most efficient way that we do this is via our Free 5-Minute security assessment, designed specifically for software startups.
Yes, it really does take only 5 minutes, then we do the rest. Once you complete the short assessment form, we craft two confidential reports - A Security Assessment report that show what your gaps and risks are, as well as A Security Recommendations Report with custom solutions and priorities that your team can either begin implementing or add to your roadmap.
1. JavaScript is an interpreted language.The JavaScript cannot execute in native machine language without a “runtime” that translates JavaScript to whatever machine language is required on the hardware (or virtual hardware) on which the JavaScript is executing. Importantly, the JavaScript runtime will be written in a much lower level programming language like C/C++