[Paper] Bit of a Close Talker: A Practical Guide to Serverless Cloud Co-Location Attacks

Source: arXiv - 2512.10361v1

Overview

Serverless platforms promise “no‑ops” infrastructure management, but they inherit a hidden risk: attackers can force their function instances to run on the same physical hardware as a victim’s, opening the door to micro‑architectural side‑channel attacks. This paper presents the first systematic, practical guide to serverless co‑location attacks, exposing weaknesses in real‑world schedulers (including Azure Functions) and proposing concrete mitigations.

Key Contributions

• Attack taxonomy for serverless – defines the steps an adversary must take to achieve co‑location using only the public function‑as‑a‑service (FaaS) APIs.
• Feature‑extraction methodology – a systematic process to discover scheduler‑exposed knobs (e.g., memory size, cold‑start latency, request timing) that can be abused for placement inference.
• Proof‑of‑concept attacks – successful co‑location on popular open‑source serverless stacks (OpenFaaS, Knative) and on Microsoft Azure Functions, demonstrating real‑world feasibility.
• Mitigation blueprint – a lightweight scheduler redesign and runtime hardening measures that dramatically reduce the attack surface without sacrificing the elasticity that makes serverless attractive.
• Open‑source tooling – released scripts and a reproducible testbed so the community can evaluate other platforms or future scheduler updates.

Methodology

1. Threat Model Definition – the attacker is a legitimate user of the same FaaS tenant, with no privileged cloud‑provider access.
2. Scheduler Feature Mining – the authors enumerate all observable parameters (memory allocation, timeout settings, warm‑start latency, request burst patterns) that influence placement decisions.
3. Placement Inference Experiments – by issuing controlled function invocations and measuring response times, they build statistical models that predict whether two functions share a host.
4. Co‑Location Orchestration – using the inferred model, the attacker iteratively adjusts request timing and resource requests until the probability of sharing a VM exceeds a chosen threshold.
5. Side‑Channel Validation – once co‑located, classic cache‑timing attacks (Prime+Probe) are launched to demonstrate data leakage potential.
6. Mitigation Evaluation – they prototype a scheduler that randomizes placement decisions and throttles fine‑grained resource requests, then re‑run the attack pipeline to quantify resilience.

Results & Findings

• High Success Rate: On Azure Functions, the attack achieved >80 % co‑location within 30 seconds of probing, comparable to results on open‑source stacks.
• Low Cost: The entire attack required only a few dollars of function execution time, showing that cost is not a barrier.
• Side‑Channel Leakage: Demonstrated extraction of cryptographic keys from a victim function using a Prime+Probe cache attack, confirming the practical impact of co‑location.
• Mitigation Effectiveness: Randomized placement reduced successful co‑location to <5 % even after prolonged probing, with negligible impact on average function latency (<2 ms overhead).

Practical Implications

• For Cloud Providers: Scheduler designs that expose fine‑grained resource knobs can be weaponized; providers should consider adding randomness and limiting per‑tenant placement visibility.
• For DevOps Teams: Monitoring for anomalous burst patterns or unusually high cold‑start rates could flag a potential co‑location attempt.
• For Security Engineers: Existing micro‑architectural mitigations (e.g., cache partitioning) become relevant again in serverless contexts; integrating them into the runtime can close the attack chain.
• For Developers: Sensitive workloads (e.g., key management, ML model inference) may need to be isolated using dedicated containers or “reserved” instances rather than relying on the default shared pool.

Limitations & Future Work

• Scope of Platforms: The study focuses on a subset of popular FaaS offerings; newer or highly customized schedulers may behave differently.
• Assumed Tenant Isolation: The attack presumes the attacker shares the same tenant; cross‑tenant co‑location remains an open question.
• Side‑Channel Diversity: Only cache‑based attacks were demonstrated; exploring other micro‑architectural vectors (e.g., branch prediction, DRAM row‑hammer) could reveal additional risks.
• Long‑Term Scheduler Evolution: Future work could integrate machine‑learning‑driven placement policies that adaptively detect and thwart inference attempts in real time.

Bottom line: Serverless isn’t automatically secure. By exposing how everyday API calls can be turned into a covert placement weapon, this research urges providers and users alike to rethink scheduler transparency and to adopt lightweight randomization defenses before side‑channel exploits become a routine part of the cloud threat landscape.

Authors

• Wei Shao
• Najmeh Nazari
• Behnam Omidi
• Setareh Rafatirad
• Houman Homayoun
• Khaled N. Khasawneh
• Chongzhou Fang

Paper Information

• arXiv ID: 2512.10361v1
• Categories: cs.CR, cs.DC
• Published: December 11, 2025
• PDF: Download PDF