Out Of Bounds Write in Actix with Hmac Signatures

An Out Of Bounds Write in an Actix-based API that uses Hmac Signatures occurs when user-controlled data influences the size or destination of a memory operation beyond allocated buffers, while the Hmac Signature is either missing, accepted without strict validation, or used inconsistently to guard message integrity. This combination can amplify impact: the signature may be verified only after or in a way that does not prevent the out-of-bounds access, or the signature covers a subset of the message that excludes length or index fields, allowing an attacker to manipulate those unchecked parts.

Consider an Actix web handler that parses a structured payload containing a length field and a byte buffer, then uses Hmac Signatures to authenticate the request. If the length field is read from attacker-controlled input and used to allocate or index a buffer without bounds checking, an oversized length can lead to a write past the end of a stack or heap buffer. Even when the request includes a valid Hmac Signature, the signature may cover the payload content but not the length field, or the server may verify the signature before validating the length. This mismatch allows an unauthenticated or low-privilege attacker to trigger the out-of-bounds write while preserving authentication integrity from the server’s perspective.

In practice, this can manifest in Actix middleware or extractors that deserialize JSON or form data into fixed-size arrays or vectors. For example, an extractor might read a chunk_size from JSON and then copy data into a fixed buffer sized for a typical request. If the Hmac Signature is computed over the serialized bytes before deserialization but the server only validates the signature after deserialization, an attacker can supply a malicious length that causes the copy to overflow. Because the signature is valid, the server may skip further integrity checks, allowing the corrupted state to propagate into business logic or downstream processing.

This pattern intersects with common CWE entries such as CWE-787 (Out-of-bounds Write) and CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) when Hmac is used incorrectly, for example by accepting any signature without verifying integrity of all relevant fields. In Actix, where handlers often chain extractors and guards, failing to validate structural constraints like length or index before using data in memory operations creates a path for corruption. Attackers can exploit this to execute code, crash services, or induce information leaks, especially when combined with other unchecked inputs or unsafe FFI boundaries.

Real-world scenarios might involve APIs that accept file-like chunks with an explicit size parameter. If the size is used to size a ring buffer or a slice without proper validation, and the Hmac Signature covers the chunk content but not the size field, an attacker can set size to a large value and cause writes beyond the buffer end. The server may log or forward corrupted data, and because the signature is considered valid, automated defenses may not flag the request as suspicious. This underscores the need to treat Hmac verification as one layer among several, including strict schema validation and bounds checks before any memory manipulation.

The risk is not only theoretical; similar patterns have been observed in frameworks where message authentication is decoupled from structural validation. Treating Hmac as a substitute for input validation is a common anti-pattern. In Actix, robust designs verify length, index, and size constraints before any buffer or collection mutation, and ensure that the Hmac Signature covers all fields that influence memory layout, with no gaps between verification and usage.

Remediation focuses on strict validation of all length and index inputs before any memory operations, and ensuring Hmac Signatures cover the full set of fields that affect buffer sizing. In Actix, implement extractors that validate bounds independently of signature checks, and structure handlers so that invalid length or index values are rejected before any buffer is allocated or written.

Use strongly typed structures with serde deserialization that enforce size constraints. For example, define a fixed-size buffer type and implement Deserialize with explicit length checks:

use actix_web::{web, HttpResponse, Result};
use serde::Deserialize;
use hmac::{Hmac, Mac};
use sha2::Sha256;

type HmacSha256 = Hmac<Sha256>;

#[derive(Deserialize)]
struct SafeChunk {
    #[serde(deserialize_with = "validate_length")]
    size: usize,
    data: Vec<u8>,
}

fn validate_length<'de, D>(deserializer: D) -> Result<usize, D::Error>
where
    D: serde::Deserializer<'de>,
{
    let candidate = usize::deserialize(deserializer)?;
    const MAX_CHUNK: usize = 4096;
    if candidate > MAX_CHUNK {
        Err(serde::de::Error::custom(format!("size exceeds maximum {}", MAX_CHUNK)))
    } else {
        Ok(candidate)
    }
}

async fn handle_chunk(
    chunk: web::Json<SafeChunk>,
    payload: web::Bytes,
) -> Result<HttpResponse> {
    // size is already validated; payload length must match size
    if payload.len() != chunk.size {
        return Ok(HttpResponse::BadRequest().body("payload length mismatch"));
    }
    // process safely within bounds
    let buffer: &[u8] = &payload[..chunk.size];
    // ...
    Ok(HttpResponse::Ok().finish())
}

Next, verify Hmac Signatures over the complete message, including fields that determine memory layout. In Actix, you can implement a wrapper extractor that validates the signature before deserialization, ensuring no unchecked fields are used:

use actix_web::dev::Payload;
use actix_web::http::header::HeaderValue;
use actix_web::Error;
use futures_util::stream::once;
use serde_json::Value;

async fn verify_hmac_body(
    mut payload: Payload,
    expected_key: &[u8],
) -> Result<Value, Error> {
    let body = web::block(move || {
        let mut mac = HmacSha256::new_from_slice(expected_key)
            .map_err(|_| actix_web::error::ErrorBadRequest("hmac init failed"))?;
        let mut chunks = Vec::new();
        while let Some(chunk) = payload.next().await {
            let data = chunk?;
            mac.update(&data);
            chunks.push(data);
        }
        let result = mac.finalize();
        let code = result.into_bytes();
        // Expect signature in header "X-API-Signature"
        let signature = HeaderValue::from_str(&format!("sha256={:?}", code))
            .map_err(|_| actix_web::error::ErrorBadRequest("invalid signature header"))?;
        // compare using constant-time logic in real code
        // For brevity, we assume validation here
        let full = chunks.concat();
        let parsed: Value = serde_json::from_slice(&full)?;
        Ok(parsed)
    })
    .await
    .map_err(|e| e.into())?;
    Ok(body)
}

Ensure that length and index fields are covered by the Hmac computation and are validated before use in any array or vector operations. Prefer fixed-size collections or checked resizing, and avoid unchecked indexing. Combine these practices with Actix’s guard mechanisms to reject suspicious requests early, reducing the chance of an Out Of Bounds Write while preserving the integrity guarantees provided by Hmac Signatures.