6.1 JWT unencrypted in HTTP connections
Connections to the L2 and builder nodes are currently allowed to be through HTTP ( http:// URL) or HTTPS ( https:// URL). Assuming the user sets up a HTTP address for a client, and, given that communication over HTTP is unencrypted, the JSON Web Tokens employed for authentication will be also unencrypted. Though with a validity period of only 60 seconds, in non-local setups (e.g., remote builder), an eavesdropper can easily sniff rollup-boost -> builder packets and gather the JWTs in use. With a hold of these, the eavesdropper can then impersonate the rollup-boost.
Recommendation
Enforce HTTPS-only connections through the setter ConnectionBuilder::https_only(), or warn the user on the use of HTTP in (possible) non-local connections.
Resolution
This mirrors the behavior of all major execution clients, which also allow JSON-RPC over HTTP even when JWT authentication is enabled. Rollup Boost follows the same model as existing Ethereum execution clients. HTTP should only used in trusted or local environments.
6.2 Server listening on all interfaces by default, without authentication
While configurable by the user, the default 0.0.0.0 makes the server accept incoming connections from any interface, possibly allowing an actor to inject malicious packets which are then signed (using rollup-boost's L2/builder JWT secrets) and forwarded to the L2 and builder nodes. The exposure of this issue is aggravated given that there is no use of an authentication mechanism for incoming messages.
Recommendation
Consider changing the default listening IP to localhost / 127.0.0.1.
6.3 Debug API authentication
The debug API allows runtime modification of critical server state ( ExecutionMode) and it doesn't seem to have any application-level authentication, security relies only on port accessibility or firewall.
Recommendation
Implement mandatory authentication.
Resolution
Rollup Boost is not intended to be publicly exposed. Therefore the authentication of the debug API is unnecessary. It's worth mentioning that the same solution is used in op-node's admin RPC.
6.4 JWT tokens timestamped 60 seconds into the future
JWT claims used in the engine API are mandated to be valid for +- 60 seconds. However, the current secret_to_bearer_header() function creates JWTs issued 60 seconds into the future. This provides a possible eavesdropper to use the JWT tokens for double their intended duration. Moreover, if the system times of the rollup-boost and the receiving node (L2 or builder) are skewed apart more than the latency between these, the receiving node will block the rollup-boost requests due to a perceived iat being more than 60 seconds into the future.
Recommendation
Remove the addition of the 60 seconds duration from the iat calculation. Use only current time.
6.5 Possible execution_mode inconsistency in get_payload
When get_payload is called the flow is:
- Try to get payload from both builder and L2 execution client;
1.1. To decide whether payload should be fetched from external builder, the execution_mode is fetched ( link) 1.2. The way it is fetched is that the mutex is locked and value is copied 2. Once payload is received, process it. 2.1. During payload processing the execution_mode is fetched yet again by locking the mutex and reading the value.
The issue is that between points 1 & 2, some time can pass, and the value of execution_mode might be changed in-between. What can happen is:
execution_mode is set to Enabled, which means the builder will start building the block;- Actor who has access to
debug_api can change execution_mode to Disabled; - Builder will return
Ok(Some(payload)); - Even though execution is set to
Disabled we will send the payload from the builder instead from the L2 Execution Client. This is because:;
let (payload, context) = match (builder_payload, l2_payload) {
(Ok(Some(builder)), Ok(l2_payload)) => {
if self.execution_mode().is_fallback_enabled() {
// Default to op-geth's payload
Ok((l2_payload, PayloadSource::L2))
} else {
Ok((builder, PayloadSource::Builder))
}
}
(_, Ok(l2)) => Ok((l2, PayloadSource::L2)),
(_, Err(e)) => Err(e),
}?;
We will end up in a branch: (Ok(Some(builder)), Ok(l2_payload)) but is_fallback_enabled will be false.
Recommendation
Read execution_mode once, at the beginning of get_payload.
6.6 Proxy does not implement rate-limiting
Rate-limiting helps protect systems from abuse, brute-force attacks, and resource overuse by restricting how often a user can make requests. While the rollup-boost main server implements some rate-limiting through jsonrpsee::Server, the proxy level (at a level above), does not implement so.
Recommendation
Implement a rate-limiting Service, add it to the ProxyService. See for example this.
Resolution
Rollup Boost is not intended to be publicly exposed. Relays or other trusted components should write directly to the proxy service. Chain operators should ensure that rate limiting is enforced elsewhere in the stack.
6.7 Use of sync::Cache in an async context
moka provides both sync::Cache and future::Cache, for use in multi-threaded and asynchronous contexts, respectively. While slightly more ( 9%) performant, sync::Cache carries some risk of blocking the async executor threads and therefore, the whole rollup-boost operation. See a more detailed discussion here. As of currently, the employed Cache methods carry a very low risk of temporarily blocking the executor.
Recommendation
Replace moka::sync::Cache by moka::future::Cache. Performance analysis comparing both.
6.8 CI GitHub Action actions-rs unmaintained
actions-rs/toolchain is a GitHub Action that provides cargo features (build, test, lint, etc.). As of currently, it is unmaintained and archived, and as such, any possible vulnerabilities will not be fixed.
Recommendation
Use cargo as already provided by the CI image ubuntu-latest, or explore other maintained Rust/ cargo GitHub Actions.
6.9 Code inside the is_fallback_enabled() branch may not be reachable
The function RollupBoostServer.get_payload ensures the execution mode is enabled before attempting to call the builder. If the execution mode disables payload retrieval (e.g., dry-run mode), the builder is not called.
async fn get_payload(
&self,
payload_id: PayloadId,
version: Version,
) -> RpcResult<OpExecutionPayloadEnvelope> {
let l2_client_future = self.l2_client.get_payload(payload_id, version);
let builder_client_future = Box::pin(async move {
let execution_mode = self.execution_mode();
// @audit @audit When fallback mode is enabled, the builder is skipped entirely
if !execution_mode.is_get_payload_enabled() {
info!(message = "dry run mode is enabled, skipping get payload builder call");
// We are in dry run mode, so we do not want to call the builder.
return Err(ErrorObject::owned(
INVALID_REQUEST_CODE,
"Dry run mode is enabled",
None::<String>,
));
}
// ...
After, the function concurrently awaits both the L2 client and the (potential) builder results using tokio::join!. It then matches the outcomes:
- If both the builder and the L2 client succeed (
Ok results), the function checks if fallback mode is enabled:;
- If fallback mode (
is_fallback_enabled()) is enabled, the L2 client's payload is chosen. - Otherwise, the builder's payload is used.
- If only the L2 client succeeds while the builder fails or returns no payload, the L2 client's payload is selected instead;
let (l2_payload, builder_payload) = tokio::join!(l2_client_future, builder_client_future);
let (payload, context) = match (builder_payload, l2_payload) {
(Ok(Some(builder)), Ok(l2_payload)) => {
if self.execution_mode().is_fallback_enabled() {
// @audit: This branch will never be executed
// Default to op-geth's payload
Ok((l2_payload, PayloadSource::L2))
} else {
Ok((builder, PayloadSource::Builder))
}
}
(_, Ok(l2)) => Ok((l2, PayloadSource::L2)),
(_, Err(e)) => Err(e),
}?;
Let's say the execution_mode is changed to fallback (i.e., self.execution_mode().is_fallback_enabled() is true) before the get_payload function is invoked. Then, builder_client_future would contains an error meaning that the dry run mode is enabled.
The code inside the is_fallback_enabled() branch is unreachable because if fallback mode is active, the builder is never called in the first place — it is skipped earlier when checking is_get_payload_enabled(). Although this branch is not executed, it does not cause incorrect behavior. The fallback logic properly defaults to selecting the L2 payload when needed.
Recommendation
Review the intended flow to ensure the unused code executes when fallback execution mode is enabled or remove it to reduce its complexity.
6.10 Incoming requests have a large size limit
The body of all incoming HTTP requests are first passed through the function http_helpers::read_body() which returns the encoded JSON bytes, if valid in the size range. Internally, this function copies the bytes into a new, returned, buffer. Given that the size limit is currently set at u32::MAX, much larger than expected requests, extra-large (and likely invalid) requests can be used to cause denial-of-service due to the resources needed to copy all of the incoming data. Moreover, the header size of incoming HTTP requests is not set.
Recommendation
Limit the size limit to values closer to expected requests. On the header size, set the maximum header size in order to prevent issues related with oversized headers.
Update from Nethermind Security
The fixing for this issue was identified in PR 221.
6.11 boost_sync flag can cause discrepancies between builder and L2 op-geth
Here is the relevant part for handling FCU requests:
// TODO: Use _is_block_building_call to log the correct message during the async call to builder
let (should_send_to_builder, _is_block_building_call) =
if let Some(attr) = payload_attributes.as_ref() {
// payload attributes are present. It is a FCU call to start block building
// Do not send to builder if no_tx_pool is set, meaning that the CL node wants
// a deterministic block without txs. We let the fallback EL node compute those.
let use_tx_pool = !attr.no_tx_pool.unwrap_or_default();
(use_tx_pool, true)
} else {
// no payload attributes. It is a FCU call to lock the head block
// previously synced with the new_payload_v3 call. Only send to builder if boost_sync is enabled
(self.boost_sync, false)
};
let execution_mode = self.execution_mode();
let trace_id = span.id();
if let Some(payload_id) = l2_response.payload_id {
self.payload_trace_context.store(
payload_id,
fork_choice_state.head_block_hash,
payload_attributes.is_some(),
trace_id,
);
}
if execution_mode.is_disabled() {
debug!(message = "execution mode is disabled, skipping FCU call to builder", "head_block_hash" = %fork_choice_state.head_block_hash);
} else if should_send_to_builder {
let builder_client = self.builder_client.clone();
tokio::spawn(async move {
let _ = builder_client
.fork_choice_updated_v3(fork_choice_state, payload_attributes.clone())
.await;
});
} else {
info!(message = "no payload attributes provided or no_tx_pool is set", "head_block_hash" = %fork_choice_state.head_block_hash);
}
Let's focus on the following scenario:
execution_mode is ExecutionMode::Enabled;- FCU is NOT a building block, but an update head;
- If
self.boost_sync is disabled, the builder won't receive the update head from the Sequencer; it will have to wait for it from its own L2 node, which can be slow(er); - The request for block building comes before the builder has had time to update the head, which results in the builder not building a block;
A similar argument can be made for the NewPayload call because it depends on self.boost_sync. This may be an even bigger issue because the builder could take too long to receive this new block via P2P (even though it's physically close to the Sequencer).
Recommendation
Maybe remove self.boost_sync altogether. There is no massive benefit in having this flag; conversely, it complicates logic and may lead to bugs.
If this is not acceptable, we recommend that if ExecutionMode::Enabled overpowers self.boost_sync, i.e., even if boost_sync is disabled, we forward requests for ExecutionMode::Enabled. This later is not the best solution because logic is still unnecessarily complex, and issues can arise (albeit highly unlikely) when ExecutionMode is changed and boost_sync is disabled.
