feat(kona-sp1): add native super-range acceptance parity#21857
Conversation
Replay collected witnesses through the shared range and consolidation cores so interop acceptance scenarios can validate SP1 checkpoints without running the expensive guest ELF. Reuse the same scenarios for FPVM, native SP1, and the single opt-in full-ELF smoke, and wire the native executor into CI.
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
| if !ok { | ||
| return false | ||
| } | ||
| cmd := exec.CommandContext(contextualT.Ctx(), exePath, args[1:]...) |
There was a problem hiding this comment.
OS Command Injection (CWE-78)
More Details
OS command injection is a critical vulnerability that allows an attacker to execute arbitrary commands on the system. This can lead to a full system compromise, as the attacker can potentially gain complete control over the application and the underlying system.
The vulnerability arises when user input is used to construct commands or command arguments that are then executed by the application. This can occur when user-supplied data is passed directly to functions that execute OS commands, such as exec.Command, exec.CommandContext, syscall.ForkExec, or syscall.StartProcess.
If an attacker can inject malicious code into these commands, they can potentially execute any command on the system, including installing malware, stealing data, or causing a denial of service. This vulnerability can have severe consequences, including data breaches, system compromise, and unauthorized access to sensitive information.
To avoid this vulnerability, user input should never be used directly in constructing commands or command arguments. Instead, the application should use a hardcoded set of arguments and validate any user input to ensure it does not contain malicious code.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood |
Remediation
OS command injection is a critical vulnerability that allows an attacker to execute arbitrary commands on the system. This can lead to a full system compromise, as the attacker can potentially gain complete control over the application and the underlying system. The vulnerability arises when user input is used to construct commands or command arguments that are then executed by the application.
To fix this issue, user input should never be used directly in constructing commands or command arguments. Instead, the application should use a hardcoded set of arguments and validate any user input to ensure it does not contain malicious code. Additionally, it is recommended to use language-specific facilities for executing commands, which provide better input validation and sanitization.
Code examples
// VULNERABLE CODE - User input is directly used in constructing the command
userInput := getInput() // Assume this comes from user input
cmd := exec.Command("/bin/sh", "-c", userInput)
err := cmd.Run()// SECURE CODE - Command and arguments are hardcoded, and user input is validated
userInput := getInput() // Assume this comes from user input
if !isValidInput(userInput) {
// Handle invalid input
return
}
cmd := exec.Command("/bin/sh", "-c", "echo", userInput)
err := cmd.Run()Additional recommendations
- Follow the principle of least privilege and run the application with the minimum required permissions.
- Use input validation and sanitization techniques to ensure that user input does not contain malicious code.
- Implement secure coding practices and follow security standards such as OWASP Top 10 and CWE.
- Consider using language-specific facilities for executing commands, such as os/exec in Go, which provide better input validation and sanitization.
- Regularly update and patch the application and its dependencies to address known vulnerabilities.
- Implement logging and monitoring mechanisms to detect and respond to potential security incidents.
Rule ID: WS-I011-GO-00026
To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason
If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).
To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate
Summary
Run SP1 super-range acceptance checks natively alongside the existing FPVM scenarios. The native executor collects real witnesses, replays them through the shared range and consolidation cores, and verifies canonical and replacement outcomes across the required interop scenarios.
CircleCI builds and runs the native executor in both acceptance variants. Full program ELF execution remains limited to one opt-in cross-chain smoke test and is never enabled in CI. This will be done in a later PR.
Meta
Part of #21624