[codex] batcher consensus proof of concept#20844
Conversation
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
![wiz-0f98cca50a[bot]](https://avatars.githubusercontent.com/u/58791460?s=60&v=4){kind=small}
| }) | ||
| listener, err := net.Listen("tcp", "127.0.0.1:0") | ||
| t.Require().NoError(err) | ||
| server := &http.Server{Handler: mux} |
There was a problem hiding this comment.
Uncontrolled Resource Consumption in Go HTTP Server (CWE-400)
More Details
The Go net/http package's default serve functions (http.ListenAndServe, http.ListenAndServeTLS, http.Serve, and http.ServeTLS) do not have configurable timeouts, making them vulnerable to resource consumption attacks like Slowloris. In a Slowloris attack, an adversary opens many connections to the server but sends data very slowly, eventually overwhelming the server's resources and preventing it from accepting new connections.
Failing to set appropriate timeouts on the HTTP server can lead to resource exhaustion, causing a denial of service. This could disrupt the application's availability and potentially enable further attacks if the server crashes or becomes unstable. To mitigate this risk, timeouts should be configured on the http.Server before starting the server.
| Attribute | Value |
|---|---|
| Impact |  |
| Likelihood | |
Remediation
The Go net/http package's default serve functions (http.ListenAndServe, http.ListenAndServeTLS, http.Serve, and http.ServeTLS) do not have configurable timeouts, making them vulnerable to resource consumption attacks like Slowloris. In a Slowloris attack, an adversary opens many connections to the server but sends data very slowly, eventually overwhelming the server's resources and preventing it from accepting new connections. This can lead to a denial of service, disrupting the application's availability and potentially enabling further attacks if the server crashes or becomes unstable.
To mitigate this risk, you should configure appropriate timeouts on the http.Server before starting the server. This can be done by creating a new http.Server instance with the desired timeout values and using its ListenAndServe or ListenAndServeTLS methods instead of the package-level functions.
Code examples
// VULNERABLE CODE - Default serve functions without timeouts
http.ListenAndServe(":8080", nil)// SECURE CODE - Configure timeouts on http.Server
server := &http.Server{
Addr: ":8080",
ReadHeaderTimeout: 5 * time.Second, // Timeout for reading the entire request header
ReadTimeout: 10 * time.Second, // Timeout for reading the entire request body
WriteTimeout: 10 * time.Second, // Timeout for writing the response
IdleTimeout: 120 * time.Second, // Timeout for idle connections
}
log.Fatal(server.ListenAndServe())Additional recommendations
- Follow the principle of least privilege and set timeouts as low as reasonably possible for your application's needs.
- Consider using a reverse proxy or load balancer with timeout configurations to add an additional layer of protection.
- Implement monitoring and alerting for slow or hanging requests to detect potential attacks early.
- Refer to the OWASP Denial of Service guidance and CWE-400 for best practices in mitigating resource consumption vulnerabilities.
- Regularly review and update timeout configurations as your application's requirements change.
Rule ID: WS-I011-GO-00018
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
1 participant
Summary
This draft PR adds a blob-mode-only batcher consensus proof of concept.
eth_callto an L1 verifier contract and skips invalid proofsop-up smoke-batcher-consensusCWSIMPLX1 || digest || marker || fixed POC envelope || Commonware certificatecalldata envelope for the Commonware sidecar pathsha256(union_unique(finalize_namespace, proposal.encode()))eth_callpath has the P256 precompile available--l2-rpc-portfor running valid and invalid demo networks side by sidePOC Caveat
The current sidecar runs a deterministic in-process Commonware Simplex network for the POC. The verifier now directly checks the Commonware secp256r1 certificate signatures in EVM, but the certificate layout and validator set are still fixed for this proof of concept rather than a production configurable committee/verifier contract.
Validation
The DevStack acceptance tests show valid Commonware consensus proof calldata advancing
local-safe, and invalid proof calldata being rejected withfalse batch consensus verifier resultwhilelocal-saferemains at genesis.The live OP Up smoke run started a valid proof demo on
http://localhost:8545and an invalid proof demo onhttp://localhost:8546;smoke-batcher-consensus allobserved the valid safe head reach the submitted transfer block and the invalid safe head stay below the submitted transfer block for 20 seconds.Note: the DevStack and OP Up runs used
DEVSTACK_L2EL_KIND=op-gethin this environment because op-reth was not built locally.