LIGO language barriers
Tezos has its own smart contract language, which has a number of benefits. However, as a relatively new and evolving language, tooling requires additional work from the auditors.
Case studies
Smart contract security audit for Allbridge Classic
AUG–SEPT 2022
Finance
Smart contracts
Allbridge's Tezos Project audit results
In the public report, we summarised the security assessment of Allbridge's Tezos Project: the process, a list of findings, theoretical and practical concerns. We would like to note the efforts that the Allbridge team has put into the security & reliability of smart contracts code and their infrastructure. The team has implemented not only 'band-aid' fixes but refactored and improved significant pieces of code based on our recommendations.
Read executive summaryOverview
Allbridge Classic is a cross-chain bridge that enables users to transfer their assets between the Tezos network and other supported blockchains (Ethereum, BNB Chain, Solana, and more). The Tezos part of the cross-chain bridge (named Tezos Project) was developed as part of a collaboration between Allbridge and MadFish Solutions teams, containing smart contacts and off-chain infrastructure.
Tezos Foundation requested a security audit of the Tezos Project from Cossack Labs. Our security engineers went through the usual audit labour: reviewed and analysed smart contracts core, tests, deployment pipelines, development processes, and surrounding infrastructure. Having validated fixes for soundness, we can now mention this project.
Industry
- FSA / Fintech
- DeFi
Technology stack
- Smart contracts
- Tezos Network
- JavaScript, Python, LIGO
Regulations
- Typical fintech security requirements
Challenges
Smart contract specific attacks
Smart contracts occupy a separate niche in the software world and have their unique attack vectors: gas exhaustion, reentrancy, front-running attacks, signature replay, malicious miners, etc. Developers should understand all these attacks to build suitable defence mechanisms.
Gas consumption issues
The Tezos blockchain uses gas as a unit of computation to limit the execution time of smart contracts, prevent infinite loops, and keep miners from abusing their computing power. The irrational usage of gas—unnecessary code pieces, uncontrollable growth of data, or calls to malicious contracts—can lead to blocking the entire contracts or user funds.
Smart contracts are more than just a code
Smart contracts require a proper surrounding infrastructure and processes: testing, deploying, updating, migrating, monitoring, and stopping in an emergency. All these procedures don't magically appear; they should be created and—preferably—automated. Often, smart contract security depends on the developer's operational security habits and how they handle sensitive admin keys and other assets.
Dependency management and vulnerability monitoring
Heavily relying on external dependencies is a common practice in modern software development. Selecting secure and reliable libraries, on-time monitoring and updating should be a part of any development process, not just for smart contracts.
Smart contracts infrastructure
Tezos Project contains a set of smart contracts that communicate with each other. Third parties can use some of the contracts from outside the Tezos Project. Thus, all entrypoints should be secured with proper input validation, covering all possible edge cases.
Technology requirements
Immutable smart contracts
Once deployed, smart contracts can not be changed or replaced easily. Developers should design the update mechanisms, like migrating the whole contract to a new version or switching its individual parts. However, it creates a trade-off between the maintainability and security of smart contracts.
A bridge works across several blockchains
A bridge provides a mechanism for different incompatible blockchain networks to interoperate. Ensuring that these components work as intended, even in unusual circumstances, is crucial to protecting users' funds and the bridge itself against abuse and misuse.
Support of token standards
The Tezos network relies on two standards for implementing tokens in smart contracts: FA1.2 and FA2. As the Tezos Project uses its own tokens, they must be compatible with standards for easy integration with other tools in the Tezos ecosystem.
Our approach
Our approach
Keen understanding of blockchain threats
Cossack Labs has been working with mature blockchain research organisations for years, dealing with cryptographic cores, wallets, smart contracts, nodes, etc. By researching vulnerabilities and fixes, monitoring ecosystems, and analysing different blockchains, we keep up-to-date with blockchain threats, security controls and mitigations.
Pragmatic security, proven methods
We apply “traditional” software security practices to novel contexts to fully comprehend threat vectors. Our team borrows verification standards from the world of distributed apps, financial security standards from banking, and development maturity guidelines from NIST. It allows benefiting from years of experience in software security.
Comprehensive security review and analysis
We go beyond code and also review use cases, tests, deployment pipelines, key management processes, user experience, integration with backends, supply chain issues, maintenance, etc. Our engineers suggest security improvements for better future reliability and development of the project. Why fix bugs if you can just prevent them?
Solution
We reinforced the Allbridge team by reviewing the consistency and security of the Tezos Project, highlighting issues, and helping the team fix them. This audit went beyond a simple smart contracts' logic verification: our engineers analysed gas usage, key management, performance, maintainability and usability issues.
We started the audit by analysing, threat modelling, and assessing the risks associated with smart contracts and off-chain entities:
- As the Tezos Project allows users to exchange tokens, we've used security standards from traditional finance as yardstick orientation (PCI DSS, SOX, etc.), NIST RMF as a risk management framework, and OWASP SAMM as best practices for software maturity processes.
- Our team identified significant risks and threat vectors based on the risk assessment results, which allowed to detect the most use cases and operations before starting an actual implementation review.
- To assess the impact of the security controls, we classified them as "broken", "missing", or "improvements" and set priorities as high, medium, or low. Clear classification allowed the development team to prioritise security-related work and understand the consequences of the found issues.
Keeping the bridge context in mind, we reviewed its design and use cases:
- Our team reviewed general architecture, components, contracts, their purposes, workflows, etc. and enriched the project's documentation with corresponding diagrams and charts.
- Due to the centralised nature of the Tezos Project, special attention was paid to the risks of abusing and misusing the bridge lifecycle by the product team and admins. We provided guidelines on how to strengthen operations and prevent accidental errors by additional checks. The expanded suggestions included deployment pipelines, contract migration strategies, functionality available for administrators, managing admin's keys, etc.
- We proposed two-step migrations to protect specific workflows of changing sensitive fields, like administrators or keys, to reduce the chance of system errors.
- To determine whether the token exchange is synchronised between different blockchains, our engineers examined the Ethereum part of the cross-chain bridge and ensured its compatibility and consistency with the Tezos part.
We conducted a security audit of smart contracts core and transactions:
- The transaction review started from a design level: the flow, sources and destinations, parameters, trust, and possible gas issues. Visualising workflows helped to spot missing steps and risky connections.
- After creating a data model for each contract and its storage, analysing data types, appropriate fields, and unused items, we recommended removing some items and changing types in others to save gas.
- The Tezos Project doesn’t store private data but still operates with sensitive information: signatures, administrator addresses, user balances, etc. We identified sensitive assets and ensured that they were handled and controlled appropriately.
- Our team reviewed each function, entrypoint, and view for unreachable code, (in)correct calculations, precision handling, type conversions, etc. All sensitive flows were covered with tests and complied with FA2 and TZIP-016 standards.
- We tested for smart contract-specific threats and attack vectors: gas exhaustion, reentrancy, front-running attacks, signature replay, malicious miners, etc.
- Along with security, security engineers considered efficiency and maintainability during the analysis and identified places for optimising gas consumption.
- To ensure that our testing is throughout, we used industry-specific checklists as guidance: Smart Contract Security Verification Standard (SCSVS) by SecuRing, Tezos security assessment checklist and Tezos security baseline checking framework by Inference.
Besides all the above, we provided recommendations for security improvements aligned with the “defence in depth” approach:
- Guidelines for improving dependency and vulnerability management processes, as the Tezos Project uses some third-party code for testing, origination, and maintaining contracts.,
- In light of the rapid growth of the LIGO ecosystem, our team recommended monitoring new compiler versions and setting up a process of updating code, as new versions bring performance, memory optimisations, and security fixes.
Results and outcomes
Tezos Foundation and Allbridge hold a comprehensive review of Tezos smart contracts as a part of the Tezos Project project. In this audit, we focused on consistency, security, and defence in depth providing recommendations on numerous fixes and improvements.
We verified existing security controls and suggested new ones, boosting Allbridge's and users' confidence in the bridge's correctness. Several improvements were made to the Tezos part of the bridge, including routines for changing sensitive parameters, more consistent functionality, compliance with FA2 and TZIP-016 standards, additional test paths, more efficient storage, and many more.
Up next
Got a challenge that's still standing?
Let’s start a conversation.