Lack of upper limit of timeout for batch HTTP request could be utilized to DoS the worker

[c4-bot-10]

Lines of code

https://github.com/code-423n4/2024-03-phala-network/blob/a01ffbe992560d8d0f17deadfb9b9a2bed38377e/phala-blockchain/crates/pink/chain-extension/src/lib.rs#L64

Vulnerability details

Impact

Pink Extension provides the possibility to make HTTP requests as a feature through a query. To prevent DoS related attacks, the HTTP request is set with a timeout of 10 seconds. This way, this feature can not be abused to overload the worker.

However, Pink Extension provides the possibility to make batch HTTP requests as well, when doing so, the timeout is an external input (i.e. dynamic value), and there is no upper limit for the timeout here.

pub fn batch_http_request(requests: Vec<HttpRequest>, timeout_ms: u64) -> ext::BatchHttpResult {
.
.
    block_on(async move {
        let futs = requests
            .into_iter()
            .map(|request| async_http_request(request, timeout_ms));	
.
.
.
fn batch_http_request(
	&self,
	requests: Vec<HttpRequest>,
	timeout_ms: u64,
) -> Result<ext::BatchHttpResult, Self::Error> {
	Ok(batch_http_request(requests, timeout_ms))
}

chain-extension/src/lib.rs#L64
chain-extension/src/lib.rs#L194

This can be abused to set too high value for the timeout (u64::MAX=18446744073709551615).

Proof of Concept

The attack path as follows:

• The maclious actor deploys a Phala contract which makes 5 HTTP request (5 is maximum) as a batch to a server that's created by the actor.

   const MAX_CONCURRENT_REQUESTS: usize = 5;  
   if requests.len() > MAX_CONCURRENT_REQUESTS {
       return Err(ext::HttpRequestError::TooManyRequests);
   }

  chain-extension/src/lib.rs#L57

• This server receives HTTP requests but it delays responses for some time (e.g 1 or 2 hours).

• The maclious actor sends a query to the worker RPC for the Phala contract.

• The contract gets executed by Pink Runtime via the worker.

• This execution will last for 1 hour (assuming the timeout set in the contract is 1 hour, can be even more).

As a consequence, the maclious actor can send too many queries to the same worker for this contract, flooding the worker, leading to a DoS eventually or even a crash since the worker could hit the hard limit of the resources set.

Tools Used

Manual analysis

Recommended Mitigation Steps

Add a upper limit for the timeout for the batch HTTP request feature.

Assessed type

DoS

[c4-pre-sort]

141345 marked the issue as duplicate of #43

[c4-judge]

OpenCoreCH changed the severity to 2 (Med Risk)

[c4-judge]

OpenCoreCH marked the issue as satisfactory