Out Of Bounds Write in Actix with Mutual Tls

An Out Of Bounds Write occurs when a program writes data outside the intended memory boundaries, often due to missing bounds checks. In Actix applications using Mutual TLS (mTLS), this risk can emerge at the intersection of certificate-based client authentication and unchecked request handling. mTLS ensures both client and server present valid certificates, but it does not inherently validate the size or structure of data within authenticated requests.

Consider an Actix-web service that terminates mTLS and then passes the authenticated principal to downstream handlers without validating payload sizes. A client with a valid certificate might send a carefully crafted request with oversized form fields, path parameters, or JSON bodies. If the application copies this data into fixed-size buffers, structures, or collections without proper length checks, it can trigger an out-of-bounds write at the memory level. This is especially relevant when integrating native extensions or FFI calls, where Rust’s safety guarantees may not cover interactions with C-based APIs.

Real-world examples include unchecked concatenation of certificate subject fields into buffers, or using unchecked indexing into arrays derived from authenticated claims. An attacker with a valid certificate could exploit this to corrupt memory, potentially leading to arbitrary code execution or denial of service. The presence of mTLS changes the threat model by narrowing the attack surface to authenticated clients, but it does not eliminate logic flaws like missing bounds checks.

middleBrick scans such setups by testing the unauthenticated attack surface and, where mTLS is required, by simulating authenticated probes. It flags indicators such as missing length validation on certificate-derived metadata and oversized payload handling, mapping findings to relevant OWASP API categories and providing remediation guidance.

Remediation focuses on validating all data derived from the mTLS handshake and authenticated client context. Even with valid client certificates, application code must enforce strict size and type checks on any data extracted from certificates or tokens.

1. Validate certificate metadata before use

Do not assume certificate fields like Common Name or SANs have bounded lengths. Explicitly check lengths before copying into buffers or collections.

use actix_web::{web, HttpResponse, Responder};
use openssl::ssl::{SslAcceptor, SslFiletype, SslMethod};

fn create_ssl_acceptor() -> SslAcceptor {
    let mut builder = SslAcceptor::mozilla_intermediate(SslMethod::tls()).unwrap();
    builder.set_private_key_file("key.pem", SslFiletype::PEM).unwrap();
    builder.set_certificate_chain_file("cert.pem").unwrap();
    builder.set_verify(openssl::ssl::SslVerifyMode::PEER | openssl::ssl::SslVerifyMode::FAIL_IF_NO_PEER_CERT, 
        |_, _| true);
    builder.build()
}

async fn handle_secure(
    req: actix_web::HttpRequest,
    body: web::Bytes,
) -> impl Responder {
    // Example: safely handle client certificate subject
    if let Some(cert) = req.certificate() {
        let subject = cert.subject_name().to_string();
        // Validate length before any buffer operations
        if subject.len() > 256 {
            return HttpResponse::BadRequest().body("Certificate subject too long");
        }
        // Safe usage after validation
        let safe_subject = subject.chars().take(256).collect::();
        HttpResponse::Ok().body(format!("Authenticated: {}", safe_subject))
    } else {
        HttpResponse::BadRequest().body("Missing client certificate")
    }
}

2. Use bounded structures for certificate-derived data

Prefer owned, bounded types like String with explicit truncation or rejection, and avoid raw pointer operations when integrating with native code.

use actix_web::web::Json;
use serde::{Deserialize, Serialize};

#[derive(Deserialize, Serialize)]
struct Claims {
    sub: String,
    scope: String,
}

async fn process_claims(Json(payload): Json) -> HttpResponse {
    // Enforce application-level bounds
    if payload.sub.len() > 128 || payload.scope.len() > 256 {
        return HttpResponse::PayloadTooLarge().body("Claim exceeds max length");
    }
    // Safe processing with bounded strings
    HttpResponse::Ok().json(serde_json::json!({
        "user": payload.sub,
        "permissions": payload.scope
    }))
}

3. Middleware for consistent validation

Implement an Actix middleware layer to validate headers, paths, and bodies before they reach business logic. This centralizes bounds checks and reduces the risk of missing a validation edge case.

use actix_web::{dev::ServiceRequest, Error, middleware::Middleware};

struct ValidationMiddleware;

impl actix_web::dev::Transform for ValidationMiddleware
where
    S: actix_web::dev::Service, Error = Error>,
    S::Future: 'static,
    B: 'static,
{
    type Response = actix_web::dev::ServiceResponse;
    type Error = Error;
    type InitError = ();
    type Transform = ValidationMiddlewareImpl;
    type Future = std::future::Ready>;

    fn new_transform(&self, service: S) -> Self::Future {
        std::future::ready(Ok(ValidationMiddlewareImpl { service }))
    }
}

struct ValidationMiddlewareImpl {
    service: S,
}

impl actix_web::dev::Service for ValidationMiddlewareImpl
where
    S: actix_web::dev::Service, Error = Error>,
    S::Future: 'static,
    B: 'static,
{
    type Response = actix_web::dev::ServiceResponse;
    type Error = Error;
    type Future = S::Future;

    fn poll_ready(&mut self, cx: &mut std::task::Context<'_>) -> std::task::Poll> {
        self.service.poll_ready(cx)
    }

    fn call(&mut self, req: ServiceRequest) -> Self::Future {
        // Validate path, headers, and extracted certificate metadata here
        // Reject if any bound is violated
        self.service.call(req)
    }
}