PaperlayerView exact revision on arXiv

Source-linked AI summary

Towards Operator-Empowered Vulnerability Hotfixing for 5G Radio Access Networks

Dong Hyeok Kim, Xin Zhe Khooi, Hocheol Nam, Seungjin Baek, Mun Choon Chan, CheolJun Park, Min Suk Kang

arXiv:2608.30615v1cs.CR

TL;DR

Cellular protocol vulnerabilities can remain exposed while permanent fixes move through standardization, vendors, and deployment. Buckler gives MNOs temporary RAN hotfixes through standardized hooks and bounded stateful rules, and its evaluation finds broad constructive coverage with small, portable changes while identifying attacks requiring endpoint capabilities beyond the RAN.

  • Problem

    Permanent remediation of known standard L2/L3 vulnerabilities can take months or years, leaving MNOs needing temporary local prevention during the disclosure-to-deployment interval.

  • Method

    Buckler combines reusable hooks at standardized RAN message boundaries with a closed, stateful match-action interface using DROP, MODIFY, and RELEASE.

  • Results

    Across 64 attacks from 23 papers, 43 had RAN intervention points and 20 received concrete Buckler hotfixes using three actions and five standardized hooks.

  • Takeaways & Limitations

    Operator-empowered hotfixing is presented as a practical, portable interim defense for RAN-accessible protocol vulnerabilities.

  • Takeaways & Limitations

    The reported hotfix count is a lower bound because unsuccessful constructive searches do not prove that no alternative rule exists.

Abstract

from arXiv · show

Cellular protocol vulnerabilities can remain exploitable for months or years while standards bodies, vendors, and mobile network operators (MNOs) coordinate permanent fixes. We present Buckler, a framework that enables an MNO to deploy temporary, local, and reversible hotfixes in its radio access network (RAN) during this exposure window. Buckler places reusable hooks at standardized L2/L3 channel boundaries and exposes a closed, stateful match-action interface with three preventive actions: DROP, MODIFY, and RELEASE. We evaluate whether this bounded design provides useful coverage without requiring extensive changes to existing RANs. From 23 papers, we identify 64 attacks rooted in standard L2/L3 protocol behavior, of which 43 provide a preventive intervention point at the RAN, and we construct Buckler hotfixes for 20 of them. All 20 hotfixes use the same rule vocabulary and only five standardized channel hooks, while the unsupported attacks expose endpoint dependencies that a RAN cannot satisfy alone. We implement the five hooks on srsRAN and OpenAirInterface with small, structurally similar changes, and demonstrate all three actions against representative availability and privacy attacks. These results establish operator-empowered hotfixing as a practical and portable interim defense and delineate the architectural limits of RAN-only prevention.

1 Introduction

Buckler addresses the months-to-years gap before permanent fixes by giving MNOs temporary, local, reversible RAN hotfixes. Its bounded interface covers many standard L2/L3 attacks with limited, portable integration effort.

  • Motivation: Permanent fixes for standard protocol vulnerabilities can take months or years, leaving deployed networks exposed after disclosure.The delay spans 3GPP agreement, specification changes, vendor adoption, and operator deployment.
  • Framework: Buckler lets MNOs deploy temporary, local, reversible mitigations using standardized RAN hooks and declarative stateful match-action rules.Rules invoke only DROP, MODIFY, or RELEASE, and the code generator translates them into inline handlers.
  • Coverage: 64 attacks were identified from 23 papers; 43 had RAN intervention points, and concrete Buckler hotfixes were constructed for 20 attacks.The 20 hotfixes used the same closed vocabulary, three actions, and five standardized channel hooks.
  • Coverage: 20 of 25 attacks preventively detectable at the RAN admitted a Buckler hotfix, showing that inline prevention can complement RAN-side detection.The 23 unsupported RAN-intervenable attacks primarily required endpoint-dependent authentication, integrity, confidentiality, or verifiable delivery.
  • Evaluation: Buckler was implemented on srsRAN and OpenAirInterface, with evaluation covering integration footprint, portability, runtime costs, and representative attacks.The prototype used an O-RAN SC near-RT RIC and exercised all three actions with RF emulation.

3 Threat Model and Hotfix Requirements

The threat model includes attacks whose standard L2/L3 messages reach or traverse the legitimate RAN, and excludes attacks requiring unseen paths or endpoint changes. Buckler’s requirements balance coverage, vendor effort, portability, and bounded operator control.

  • Threat Model: The threat model covers four adversary types whose relevant protocol messages reach or traverse the operator’s legitimate RAN.These include malicious UEs, MitM relays, signal injectors, and passive eavesdroppers.
  • Scope: RAN intervention requires the attack to manifest in standard L2/L3 messages that the legitimate RAN can observe and act upon.The criterion is assessed per attack, not solely by adversary type.
  • Scope: Standalone fake-base-station attacks and attacks confined to core, application, physical-signal, UE, or core-network domains are excluded.A standalone FBS terminates exchanges locally, preventing the legitimate RAN from observing or enforcing against exploit messages.
  • Requirements: Hotfix coverage requires expressive and extensible hooks and operations that expose relevant message context while supporting newly disclosed attacks without vendor-specific additions.The interface must encode different messages, protocol states, procedures, and mitigation actions using existing hooks and operations.
  • Requirements: Deployment footprint requires few small implementation sites at standardized message boundaries, allowing the same logical hooks across compliant RAN implementations.Portability is defined against standardized protocol boundaries rather than vendor-specific functions or software structures.
  • Requirements: Operational simplicity requires a closed set of defined operations and parameters instead of arbitrary code execution or complex implementation-specific state.Bounded semantics support rule inspection, management, and pre-enforcement validation.
  • Design Trade-offs: Coverage, integration effort, and operator manageability trade off: broader hooks or permissive rules may increase coverage but also implementation and management burdens.Buckler is evaluated as a practical point within this design space.

4 Buckler: A Bounded Hotfix Design

Buckler defines a bounded, portable hotfix design that attaches stateful match-action rules to standardized RAN message boundaries. Its lifecycle covers declarative construction, operator management, deployment, and inline enforcement, while deliberately limiting actions and scope for predictability.

  • Design rationale: Buckler derives its design from the need to balance broad attack coverage with a small, portable extension to existing RAN implementations.The design constrains both hook placement and rule semantics to preserve deployment footprint and operational simplicity.
  • Hook placement: Hotfixes attach to standardized logical and transport channel boundaries using protocol state maintained in the RAN.These reusable hooks cover standard L2/L3 messages handled by the RAN without requiring vendor-internal hooks for every vulnerable procedure.
  • Rule interface: The closed declarative rule vocabulary supports validation of types, parameters, and resource use while excluding arbitrary executable code.The interface therefore favors auditable, predictable intervention over unrestricted expressiveness; protocol-level review and testing remain necessary.
  • Rule interface: Buckler uses stateful match-action rules that inspect current messages, per-connection state, and RAN-wide aggregates before invoking DROP, MODIFY, or RELEASE.State updates provide bookkeeping for predicates, while preventive actions intervene when a rule condition holds.
  • Scope boundary: Buckler intentionally excludes arbitrary message synthesis, scheduling, and new cryptographic processing because these can exceed RAN-local control or reduce predictability.Section 5 tests whether the resulting bounded design still provides useful coverage across the attack corpus.
  • Hotfix lifecycle: Each hotfix proceeds through construction, management, deployment, and inline enforcement on the RAN message path.The expert creates a descriptor, the xApp manages it through the near-RT RIC, and the vRAN agent loads generated handlers at selected hooks before vulnerable default processing.

1. Hotfix construction (§4.3)

Hotfix construction expresses a mitigation as a declarative descriptor containing bounded stateful match-action rules. The descriptor declares bookkeeping state and supported operations that runtime components can instantiate at standardized channel hooks.

  • Rule construction: Buckler rules can match current-message fields, per-connection state, and RAN-wide aggregate quantities.State may derive from earlier messages or maintained counts, enabling conditions that depend on protocol history and broader RAN context.
  • Descriptor format: A YAML descriptor contains only declared state objects and a finite sequence of supported field, comparison, lookup, update, and intervention operations.It admits neither loops nor operator-supplied executable code, allowing malformed parameters and unsupported operations to be rejected before installation.
  • Descriptor deployment: The Buckler xApp parses submitted descriptors, manages their lifecycle, and sends corresponding requests over the standardized E2 interface.At runtime, the Buckler agent instantiates predefined templates and installs generated code at standard channel hooks.

5 Corpus-Wide Design Validation

Buckler’s corpus analysis tests whether a bounded, stateful RAN interface can cover diverse L2/L3 attacks while remaining portable and operationally simple. The results show meaningful coverage and reuse, while unsupported cases reveal architectural limits of RAN-only prevention.

  • Coverage: Each Buckler-hotfixable attack has a trigger and condition available at a standard hook, uses only maintained RAN state, and removes a necessary attack precondition.The rule must preserve compliant protocol operation or limit side effects to an explicit, bounded recovery cost.
  • Bounded interface: All 20 hotfixes use the same closed vocabulary: 12 use DROP, six MODIFY, and two RELEASE, with conditions based on messages, connection states, or cross-connection aggregates.None requires executable operator code, vendor-internal state, or an attack-specific action extension.
  • Bounded interface: Across the 20 hotfixes, descriptors have medians of 2 handlers, 2 state objects, 2 predicates, and 2 state updates, with at most 4 handlers and 4 state objects.These measurements make the claimed operational simplicity concrete within the closed rule language.
  • Extensibility: Five standard channel hooks suffice through the corpus timeline, while DROP, MODIFY, and RELEASE all appear by 2019 and no later constructed hotfix requires another hook.The five hooks are DCCH, CCCH, PCCH, DL-SCH, and UL-SCH; retrospective saturation does not guarantee future attacks will require no new capability.
  • Architectural limits: 23 RAN-intervenable attacks remain unsupported because their direct countermeasures require endpoint-dependent authentication, integrity, confidentiality, or verifiable delivery.These capabilities cannot be supplied unilaterally by the RAN, so the cases delineate an architectural boundary rather than a need for arbitrary RAN code.

6 Implementation and Evaluation

Buckler was implemented across two open-source RAN stacks and evaluated for portability, attack prevention, and runtime and operational costs. The experiments show that the same bounded abstraction supports representative DROP, RELEASE, and MODIFY hotfixes with modest integration and runtime overhead.

  • 6.1 Prototype and Testbed: Buckler instruments five standardized channel paths in srsRAN and OpenAirInterface using eBPF hooks.The instrumented paths are DCCH, CCCH, PCCH, DL-SCH, and UL-SCH.
  • 6.2 Integration Footprint and Cross-Implementation Portability: 160 LoC in OAI and 326 LoC in srsRAN implement all five hooks.The base Janus integration requires 90 LoC in OAI and 264 LoC in srsRAN; average per-hook additions are 14 and 12 LoC, respectively.
  • 6.2 Integration Footprint and Cross-Implementation Portability: The same five logical hooks and operator-facing hotfix abstraction map to both stacks despite different internal implementations.The stacks expose standardized message classes, raw payloads, and connection identifiers at corresponding protocol boundaries.
  • 6.3 End-to-End Hotfix Effectiveness: The representative experiments demonstrate DROP for blind DoS, RELEASE for BTS resource depletion, and MODIFY for the CA side channel.The blind DoS rule suppresses conflicting requests, the BTS rule bounds attacker-created state, and the CA rule rewrites activation bitmaps.
  • 6.4 Runtime and Operational Costs: 3.55% CPU utilization increase for blind DoS and 1.57% for BTS depletion accompany at most 3.37% higher mean RRC response latency.Loading both hotfixes increases CPU utilization by 3.80%.
  • 6.4 Runtime and Operational Costs: 356.9 ms installs and 55.5 ms withdrawals show that hotfixes can be changed on a live RAN without interrupting messages at the affected hook.Both operations are dominated by the underlying code insertion mechanism rather than Buckler itself.

7 Discussion

The discussion frames Buckler’s coverage results as constructive evidence with explicit architectural and methodological boundaries. It also emphasizes that hotfix construction and validation remain expert-driven rather than fully automated.

  • Coverage Boundary: 20 constructed hotfixes establish a lower bound on coverage, not complete coverage of all L2/L3 attacks.Failure to find a rule does not prove that no rule exists because construction depends on identifying both a RAN-controlled precondition and a separating unsafe condition.
  • Coverage Boundary: The 23 unsuccessful cases primarily require endpoint-dependent authentication, confidentiality, or delivery verification beyond a RAN-only design.A different attack-specific insight could still expose a RAN-local precondition without changing Buckler’s interface.
  • AI-assisted Hotfix Construction: Buckler does not automate hotfix derivation: protocol experts must identify intervention points and assess effects on compliant executions.LLMs could propose rules, but each candidate still requires protocol review and testing.
  • AI-assisted Hotfix Construction: The bounded descriptor vocabulary limits assisted constructions but does not establish semantic correctness of the resulting rule.Validation by the hotfix developer and deploying MNO remains necessary.
  • Limitations: The study uses a venue-, year-, and title-bounded corpus and two open-source RAN stacks in LTE configurations.Portability to proprietary stacks and end-to-end operation on a native 5G deployment remain to be demonstrated.

8 Related Work

Prior O-RAN work improves operator visibility into cellular attacks but does not provide general inline intervention. Buckler addresses this gap by adding standard-message-level enforcement for operator-deployed hotfixes.

  • O-RAN Security: O-RAN’s open interfaces, RICs, and third-party xApps introduce documented security concerns and attack surfaces.Related defenses include fine-grained xApp authorization and zero-trust designs.
  • Security through O-RAN Programmability: 5G-Spector, Spot-light, and Dai et al. use O-RAN programmability or radio-signal data for attack detection and visibility.These systems expose security-relevant observations to operator applications rather than enforcing message-level prevention.
  • Security through O-RAN Programmability: Janus provides the dynamic instrumentation substrate adopted by Buckler’s prototype.Buckler uses it to support inline intervention in running RAN software.
  • Buckler’s Position: Buckler adds standard-message-level enforcement because separate vendor controls for every new attack would not be practical.Its interface is intended to be fine-grained enough for broad mitigation while remaining general and bounded across implementations.

A Detailed Corpus Analysis

The corpus analysis illustrates how Buckler rules translate attack-specific protocol weaknesses into RAN-local interventions. Examples span dropping, modifying, and releasing messages or connections to address availability and privacy attacks.

  • Availability Attacks: CAG list deletion is prevented by dropping a Registration Request that omits the serving RAN’s CAG.The UE can then time out and attempt reconnection instead of deleting its CAG list after an explicit rejection.
  • Privacy Attacks: An uplink IMSI extractor can be addressed by modifying the first Identity Request to request a temporary identity instead of the permanent IMSI.The attack otherwise induces the UE to reveal its IMSI after a spoofed attach request.
  • Identity Spoofing Attacks: Remote de-registration and SMS phishing can be mitigated by preventing spoofed connections or sanity-checking their NAS payloads.The relevant spoofed connections use another user’s TMSI and can affect a benign UE or impersonate it.
  • Capability Manipulation Attacks: Selective service denial and authentication sync failure use stored capability lists to deny or drop mismatching downgraded requests.The stored initial capability list provides the comparison context for both attacks.
  • Privacy Attacks: Paging timing correlation is mitigated by adding dummy identities so observed paging identities no longer isolate the victim.The attack correlates triggered paging timing with the victim’s identity and presence in a cell.
  • Authentication and Replay Attacks: NAS counter reset is addressed by dropping a Security Mode Complete whose sequence number is zero when the transmitted command was not zero.This keeps the AMF’s uplink counter aligned with the UE’s counter.
  • Confidentiality Attacks: Keystream reuse is mitigated by rewriting a reused dedicated bearer identity to the next unused value.The RAN tracks bearer identities already used on each connection.
  • Availability Attacks: Radio resource draining is addressed by dropping large buffer-status reports once their rate exceeds legitimate traffic patterns.The scheduler then does not act on the forged buffer report.

B On Detectability and Hotfixability

Buckler-hotfixability is stricter than detectability when prevention requires acting before an attack takes effect, but it can also cover passive exploits that lack detectable attack triggers.

  • The comparison shows that detection and hotfixability overlap but impose different requirements: prevention may act on vulnerable message types without distinguishing attack instances.This distinction explains why some attacks are detectable only after harm occurs, whereas passive side-channel attacks can remain preventable.
  • Of 15 5G-Spector-detectable attacks, 7 are not Buckler-hotfixable because Buckler requires preventive rather than postmortem detection.Postmortem detection observes consequences after the RAN can no longer intervene.
  • The downlink DoS is detectable but not hotfixable because its detection signal occurs after the malicious message has already reached the UE.The missing Authentication Response or Failure reveals the completed DoS, leaving no intervention point.
  • 1 attack is Buckler-hotfixable but not 5G-Spector-detectable: TORPEDO can be prevented by treating every vulnerable paging message as actionable.Because the side channel is always present, there is no anomalous event for 5G-Spector to detect, while prevention can remove the exploitable property from each message.

C Additional Hotfix Portability Evaluation

The BTS resource-depletion hotfix transfers from srsRAN to OAI unchanged at the descriptor and operator-parameter levels, with adaptation confined to stack-specific hook adapters.

  • The OAI evaluation loads the BTS resource-depletion hotfix using the identical descriptor and operator-level parameters from the srsRAN evaluation.The two RAN stacks expose the same standardized message boundaries and state despite differing internal functions and data structures.
  • On OAI, the hotfix bounds attacker-created dummy RRC connections around the configured threshold of ten instead of allowing accumulation until the RAN crashes.This reproduces the behavior observed across the portability evaluation.
  • The result confirms that hotfix logic is reusable across OAI and srsRAN, while stack-specific adaptation remains confined to hook adapters.The operator-provided descriptor does not change between implementations.

D Patch Rule Descriptor Examples

The examples show declarative descriptors combining message-type matches, field extraction, stateful map and counter updates, and actions such as release across several RAN hooks.

  • The blind DoS descriptor matches RRC connection messages and maintains inbound and outbound RNTI–TMSI maps through extraction, lookup, update, and deletion operations.Its example spans rrcConnectionRequest, rrcConnectionSetup, and rrcConnectionRelease message types.
  • The BTS-depletion descriptor tracks RRC connection state with inbound and outbound counters and RNTI lists, then uses release as a preventive action.The listing includes rrcConnectionSetup and rrcConnectionRelease processing plus linked DL/UL CCCH codelets.
  • The CA side-channel descriptor includes an SCELL_ACTIVATION message match and map-update operations targeting the TMSI–RNTI state.These entries illustrate that the same descriptor vocabulary can express both matching and state updates.
Loading 2608.30615v1…