Prepared by:
HALBORN
Last Updated 02/09/2025
Date of Engagement: January 13th, 2025 - January 17th, 2025
Summary
100% of all REPORTED Findings have been addressed
All findings
2
Critical
0
High
0
Medium
0
Low
0
Informational
2
Table of Contents
1. Introduction
Autheo engaged Halborn to conduct a security assessment on their app chain module beginning on January 13th, 2025 and ending on January 23rd, 2025. The security assessment was scoped to the Cosmos-SDK Golang application provided to the Halborn team. Commit hashes and further details can be found in the Scope section of this report.
2. Assessment Summary
The team at Halborn was provided two weeks for the engagement and assigned two full-time security engineers to assess the security of the Autheo platform. The security engineers are blockchain and smart-contract security experts with advanced penetration testing and smart-contract hacking experience, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that the Golang components and Smart Contracts operate as intended.
Identify potential security issues with the Cosmos application and Smart Contracts in scope.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were partially addressed by the Autheo team. The main ones were the following:
Lock the pragma version to the same version used during development and testing.Modify the SetGuageWithLabels function in the telemetry package to accept the float64 data type.
3. Test Approach and Methodology
Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the custom modules. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of structures and can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment :
Research into architecture and purpose.
Static Analysis of security for scoped repository, and imported functions. (e.g.,
staticcheck,gosec...)Manual Assessment for discovering security vulnerabilities on the codebase.
Ensuring the correctness of the codebase.
Dynamic Analysis of files and modules in scope.
4. RISK METHODOLOGY
4.1 EXPLOITABILITY
Attack Origin (AO):
Attack Cost (AC):
Attack Complexity (AX):
Metrics:
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
4.2 IMPACT
Confidentiality (C):
Integrity (I):
Availability (A):
Deposit (D):
Yield (Y):
Metrics:
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
4.3 SEVERITY COEFFICIENT
Reversibility (R):
Scope (S):
Metrics:
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
5. SCOPE
- docs/docs.go
- testutil/simapp/simapp.go
- proto/e2ee/query.proto
6. Assessment Summary & Findings Overview
Critical
0
High
0
Medium
0
Low
0
Informational
2
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Floating pragma | Informational | Solved - 01/31/2025 |
| Integer truncation | Informational | Acknowledged - 01/31/2025 |
7. Findings & Tech Details
7.1 Floating pragma
//
Description
All contracts in scope currently use floating pragma versions ^0.8.4 , ^0.6.8 , and ^0.6.1 which means that the code can be compiled by any compiler version that is greater than or equal to the respective version, and less than the next major version (0.9.0 or 0.7.0 respectively).
However, it is recommended that contracts should be deployed with the same compiler version and flags used during development and testing. Locking the pragma helps to ensure that contracts do not accidentally get deployed using another pragma. For example, an outdated pragma version might introduce bugs that affect the contract system negatively.
Additionally, from Solidity versions 0.8.20 through 0.8.24, the default target EVM version is set to Shanghai, which results in the generation of bytecode that includes PUSH0 opcodes. Starting with version 0.8.25, the default EVM version shifts to Cancun, introducing new opcodes for transient storage, TSTORE and TLOAD.
In this aspect, it is crucial to select the appropriate EVM version when it's intended to deploy the contracts on networks other than the Ethereum mainnet, which may not support these opcodes. Failure to do so could lead to unsuccessful contract deployments or transaction execution issues.
BVSS
Recommendation
Lock the pragma version to the same version used during development and testing. Additionally, make sure to specify the target EVM version when using Solidity versions from 0.8.20 and above if deploying to chains that may not support newly introduced opcodes.
Remediation
SOLVED: The Autheo team has followed the recommendation and successfully resolved the issue.
Remediation Hash
References
7.2 Integer truncation
//
Description
A vulnerability exists in the project due to an unsafe conversion from an int64 to a float32. This results in integer truncation, where the precision of large integer values is lost during the conversion process. The float32 type cannot accurately represent all integers within the range of an int64, leading to incorrect or imprecise values being used in downstream logic.
Root Cause
The int64 type in Go can represent integers up to 263−12^{63} - 1263−1 without any loss of precision. However, the float32 type uses a 23-bit significand, which limits its ability to store precise integer values beyond 2242^{24}224. When an int64 is converted to a float32, only the most significant bits are retained, and the less significant bits are truncated, resulting in a loss of precision. This truncation can lead to the following:
Misrepresentation of large integer values.
Errors in logic that rely on precise numerical comparisons or calculations.
Impact
This vulnerability can have serious consequences in systems where:
Precise numerical calculations are critical (e.g., financial systems, counters, or unique identifiers).
The truncated value is used in sensitive operations, such as database queries, cryptographic calculations, or access control logic.
After review of the use of functions containing this vulnerability, the impact of this finding was modified to informational.
BVSS
Recommendation
To eliminate this issue, modifying the SetGuageWithLabels function in the telemetry package to accept the float64 data type is a possible approach.
Remediation
ACKNOWLEDGED: The Autheo team has acknowledged the issue.
References
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
Table of Contents
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed