| Audit Date | Oct 2nd 2024 - Oct 3rd 2024 |
| Auditor | 3DOC Security (@3docSec) |
| Version 1 | Oct 3rd 2024. |
- Audit Report - OP cannon
- Contents
- Disclaimer
- About 3DOC
- Scope
- Severity Classification
- Summary
- Findings
The following audit report is based on the information and code provided by the client, and any findings or recommendations are made solely on the basis of this information. While the Auditor has exercised due care and skill in conducting the audit, it cannot be guaranteed that all issues have been identified and that there are no undiscovered errors or vulnerabilities in the code.
Furthermore, this report is not an endorsement or certification of the protocol, and the Auditor does not assume any responsibility for any losses or damages that may result from the use of the smart contracts, either in their current form or in any modified version thereof.
3DOC is a top ranked Smart Contract Auditor doing audits on Code4rena (www.code4rena.com), having ranked 1st in multiple contests in solo and team audits, including the Optimism superchain contest in July 2024.
He can also be booked for conducting Private Audits.
Contact:
X: @3DocSec
e-mail: [email protected]
The scope of the audit is the following Pull Request in the client's GitHub repository:
The change consists of a core update for supporting the F_GETFD syscall in the MIPS VM, provided with this commit, and several additional updates accommodating the VM version bump that came with the core change.
| Severity | Impact: High | Impact: Medium | Impact: Low |
|---|---|---|---|
| Likelihood: High |  |
|
 |
| Likelihood: Medium | |
|
 |
| Likelihood: Low | |
|
|
Impact - the technical, economic and reputation damage of a successful attack
Likelihood - the chance that a particular vulnerability is discovered and exploited
| Severity | Total |
|---|---|
|
0 |
|
0 |
|
0 |
 |
0 |
The change in scope added a new implementation of the Cannon VM, which was called VersionSingleThreaded2. Cannon has now three versions (VersionSingleThreaded, VersionSingleThreaded2, and VersionMultiThreaded).
The op-challenger program makes use of the Cannon VM in several places via the configured VmBin path, which point to the multicannon command line. This one reads the State version from the input state and selects the right Cannon VM accordingly (cannon/multicannon/exec.go:L81).
If we look at the Docker challenger image generated by the make golang-docker command, however, we can see it doesn't contain an embeds folder:
docker run -t us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger find / -name embeds
But it however has the cannon command pointing to the multicannon multiplexer:
➜ optimism git:(52d0e60c1) ✗ docker run -t us-docker.pkg.dev/oplabs-tools-artifacts/images/op-challenger cannon | head -2
NAME:
multicannon - MIPS Fault Proof tool
➜ optimism git:(52d0e60c1) ✗
This issue appears to be pre-existing to the changes in scope; using Docker images to run the challenger is mentioned as option, but only as alternative option, hence the Low risk assessed for this finding.
Because of this issue, challenger instances operated in a Docker container won't be able to function properly.
Consider modifying the Docker build chain to include the embeds folder.
Consider extending the current e2e test suite to cover execution from Docker images.
@inphi The cannon-2 implementation that supports go1.22 is now embedded into the cannon cli binary. Note that these embeds are not actual files that you can find in the docker container filesystem. But rather an embedded filesystem inside the Go binary - https://pkg.go.dev/embed.
@3DOC Oh yes I see that. So those are included in an embedded filesystem, I missed that