Halborn Completes Audit of Neon’s Governance Programs

Neon Labs
Neon Labs
Published in
4 min readOct 18, 2022

Halborn, a security engineering team, has completed a security audit of Neon’s Governance Programs. The audit began on April 27, 2022 and ended on May 8, 2022. This security audit was conducted in addition to Ackee Blockchain’s audit, which was completed on July 22, 2022.

A final report was delivered to the Neon Labs team at the end of the audit process. In this article, we’ll go over the scope, goals, process, and significant findings of the Halborn security audit as documented in the final audit report.

Scope of the Security Audit

The security assessment was scoped to two Solana programs: the spl-governance-addin-fixed-weights contract and the spl-governance-addin-vesting contract. The specific commit audited was c0c3732cf0aa0b90527f54a0068367d8d03af748 of the nonlabsorg/neon-spl-governance repository. These programs are related to Neon project governance and rely on SPL-Governance and various other Solana libraries to deliver a custom governance process for participants in the Neon ecosystem.

External libraries and finance-related attacks were out-of-scope for the Halborn audit.

Purpose and Goals of the Security Audit

Neon Labs continuously emphasizes the importance of high security standards. This is why the team decided to work with Halborn, as well as Ackee Blockchain, to review Neon’s Governance contracts. The security audits were conducted to ensure that the in-scope Solana programs were functioning properly and identify potential security vulnerabilities.

The Security Audit Process

Halborn used a combination of manual code review and automated security testing to deliver an accurate auditing service while keeping efficiency, timeliness and practicality in mind. Manual testing is primarily used to uncover flaws in logic, process, and implementation. To supplement manual testing, automated testing techniques help to improve program coverage and quickly identify items that do not adhere to security best practices.

The audit procedure and associated tools are as follows:

  1. Research the architecture, purpose, and use of the Neon platform.
  2. Review and walkthrough the Solana program manual code review to identify logic issues.
  3. Thoroughly assess the safety and usage of critical in-scope Rust variables and functions that could lead to arithmetic vulnerabilities.
  4. Find unsafe Rust code usage with the cargo-geiger security tool, which lists statistics related to the use of unsafe Rust code present in a Rust codebase and its dependencies.
  5. Scan dependencies for known vulnerabilities with the cargo audit tool, which scans for vulnerabilities reported to the RustSec Advisory Database. The RustSec Advisory Database stores all vulnerabilities published in https://crates.io.
  6. Deploy the local cluster (solana-test-validator).
  7. Scan for common Solana vulnerabilities using soteria, a security analysis service for Solana programs that assists with the detection of well-known security issues.

Outcome of the Neon EVM Security Audit

Halborn ranks vulnerabilities or issues by calculating the likelihood of a security incident and the impact if an incident occurs. The likelihood and impact ratings are then ingested into a scoring framework to determine a risk’s severity level (informational, low, medium, high, and critical). The framework is useful for communicating the characteristics and consequences of technological vulnerabilities. The quantitative model ensures consistent and accurate measurement while also allowing users to see the underlying vulnerability characteristics considered when prioritizing risks.

As an output to the security audit, Halborn identified two main risks: (HAL-01) Cargo Overflow Checks Missing and (HAL-02) Outdated Dependencies Version. Both risks have now been addressed by the Neon Labs team. Additional details can be found below.

Cargo Overflow Checks Missing (HAL-01)

It was observed that there is no overflow-checks=true in any Cargo.toml file. By default, overflow checks are disabled in optimized release builds. Therefore, if there is an overflow in the release build, it will pass silently, causing unexpected behavior of an application. Even when checked arithmetic is used (checked_*), it is still recommended to have those checks in Cargo.toml.

The finding was rated as low-risk and has since been addressed. The Neon Labs team fixed the issue by adding overflows-check=true in the workspace Cargo.toml file in commit 5425078d1c45c62f92b5bb90492bbaeac751ec7b.

Outdated Dependencies Version (HAL-02)

Software is continuously updated for various reasons. Drivers introduce updates including adding new features, removing old features, and patching bugs and vulnerabilities. The Halborn team detected that the versions of spl-governance-addin-vesting and spl-governance-addin-fixed-wights packages assessed referenced outdated versions of solana-program and spl-token, which could cause logic flows to malfunction.

The finding was rated as an informational risk and has since been addressed. The Neon Labs team fixed the issue by updating solana-program and spl-token to their latest versions in commit 5425078d1c45c62f92b5bb90492bbaeac751ec7b.

Conclusion

Thank you for taking the time to review the outcome of the Halborn security audit. If you have any questions about the security audit or the associated findings, don’t hesitate to reach out. You can contact the team via Discord. Lastly, stay connected with the team on Twitter, GitHub, YouTube, and Medium for more development updates and announcements.

--

--