feat(op-wheel): add reth support for offline rewind and db inspection#20010
feat(op-wheel): add reth support for offline rewind and db inspection#20010
Conversation
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
![wiz-inc-a178a98b5d[bot]](https://avatars.githubusercontent.com/u/58791460?s=60&v=4){kind=small}
| backoffLimit: 0 | ||
| ttlSecondsAfterFinished: 86400 | ||
| template: | ||
| spec: |
There was a problem hiding this comment.
Service Account Token Automount Not Disabled
on resource metadata.name={{reth-rewind}}.spec.template.spec
More Details
This rule checks if Kubernetes workloads have service account token automounting disabled. The rule fails if automountServiceAccountToken is explicitly set to true on the pod/workload, or if it's undefined at both the pod and service account level, or if the referenced service account has automountServiceAccountToken set to true. Service account tokens provide identity for pods to communicate with the Kubernetes API server. When automatically mounted, these tokens are available to any container in the pod, which increases the attack surface in case of a container compromise. An attacker who gains access to a container with an automounted token could use it to query the Kubernetes API and potentially escalate privileges. Following the principle of least privilege, tokens should only be mounted for pods that actually need to communicate with the Kubernetes API.
Expected
metadata.name={{reth-rewind}}.spec.template.spec.automountServiceAccountToken should be defined and set to false
Found
metadata.name={{reth-rewind}}.spec.template.spec.automountServiceAccountToken is undefined
Security Frameworks: wf-id-199, wf-id-1
Rule ID: a466201b-b5c3-406c-87e3-639872ffd83b
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
| "to-block", strconv.FormatUint(toBlock, 10), | ||
| } | ||
|
|
||
| return exec.CommandContext(ctx, resolvedPath, args...), nil |
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
To remediate this vulnerability, follow these recommendations:
- Never use user-supplied input directly in constructing commands or command arguments.
- Validate and sanitize all user input before using it in any context.
- Use a hardcoded set of arguments for executing OS commands.
- If filenames are required, use a hash or unique identifier instead of the actual filename.
- Consider using a native library that implements the required functionality instead of executing OS commands.
Example of safely executing an OS command:
userData := []byte("user data")
// Create a temporary file in the application-specific directory
f, err := ioutil.TempFile("/var/app/restricted", "temp-*.dat")
if err != nil {
log.Fatal(err)
}
if _, err := f.Write(userData); err != nil {
log.Fatal(err)
}
if err := f.Close(); err != nil {
log.Fatal(err)
}
// Pass the full path to the binary and the name of the temporary file
out, err := exec.Command("/bin/cat", f.Name()).Output()
if err != nil {
log.Fatal(err)
}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
| args := []string{"db", "--datadir", datadir, "--chain", chain} | ||
| args = append(args, subArgs...) | ||
|
|
||
| return exec.CommandContext(ctx, resolvedPath, args...), nil |
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
To remediate this vulnerability, follow these recommendations:
- Never use user-supplied input directly in constructing commands or command arguments.
- Validate and sanitize all user input before using it in any context.
- Use a hardcoded set of arguments for executing OS commands.
- If filenames are required, use a hash or unique identifier instead of the actual filename.
- Consider using a native library that implements the required functionality instead of executing OS commands.
Example of safely executing an OS command:
userData := []byte("user data")
// Create a temporary file in the application-specific directory
f, err := ioutil.TempFile("/var/app/restricted", "temp-*.dat")
if err != nil {
log.Fatal(err)
}
if _, err := f.Write(userData); err != nil {
log.Fatal(err)
}
if err := f.Close(); err != nil {
log.Fatal(err)
}
// Pass the full path to the binary and the name of the temporary file
out, err := exec.Command("/bin/cat", f.Name()).Output()
if err != nil {
log.Fatal(err)
}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
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #20010 +/- ##
===========================================
- Coverage 76.4% 74.3% -2.2%
===========================================
Files 699 194 -505
Lines 74905 10852 -64053
===========================================
- Hits 57271 8069 -49202
+ Misses 17490 2639 -14851
Partials 144 144
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
1 participant
Summary
Adds reth support to op-wheel. Reth's
debug_setHeadRPC is a no-op, so the existingengine rewindflow (which relies on it for deep rewinds) doesn't work with reth. Instead, reth requires an offlinereth stage unwindCLI invocation with the node stopped.This PR adds:
engine rewind-reth— offline chain rewind by shelling out toreth stage unwind to-block <N>. Designed for K8s Jobs that mount the same PVC as the reth StatefulSet.cheat-reth head— offline head inspection viareth db stage-checkpoints get.cheat-reth state— offline account state inspection (balance, nonce, storage) viareth db state <address> --format json.rethFlags()helper for the common--reth-binary,--reth-datadir,--reth-chainflag set. All flags support env vars for K8s ConfigMap injection.optimism-charts/charts/node/charts/op-reth.reth node --dev.