Hack@CHES 2026 - Phase 1 Bug Submissions

Team KattangalSec

View on GitHub

Bug 02 - CTN Access-Range Check Permanently Overridden (Secure-Island Boundary Bypass)

Legacy reference: Bug #8 in the working set


Security feature bypassed

CTN (Chip-to-Network) address-range and permission isolation - the RACL (Resource Access Control List) boundary of the Darjeeling Secure Island SoC

Attack type

Type 1 - unprivileged software (via the CTN interface)

Finding

ac_range_check_overwrite_i is hardwired to MuBi8True in the Darjeeling chip-level template, permanently bypassing all CTN address-range and permission checks. A TODO comment in the code marks it as temporary:

// chiplevel.sv.tpl:842-844
// TODO: Override all access range checks for now.
prim_mubi_pkg::mubi8_t ac_range_check_overwrite_i;
assign ac_range_check_overwrite_i = prim_mubi_pkg::MuBi8True;

In ac_range_check.sv, a request is granted when either the address falls inside an enabled range with proper permissions or range_check_overwrite_i is true:

assign range_check_grant = ctn_tl_h2d_i.a_valid & (
                             (|addr_hit & (grant_mask > deny_mask)) |
                             prim_mubi_pkg::mubi8_test_true_strict(range_check_overwrite_i) );

With the override permanently true, every valid CTN access is granted, skipping the RACL checks entirely. A correct check (overwrite=MuBi8False) with default all-zero RANGE_BASE/LIMIT and RANGE_ATTR.enable=MuBi4False yields addr_hit=0 - range_check_fail=1

Location or code reference

New Tools

No automated detection tool. Identified by manual RTL inspection of the chip-level template (search for override signals), confirmed against the generated ASIC netlist, and validated in full-SoC simulation under Synopsys VCS U-2023.03 via dvsim.

AI Tools

Yes - DeepWiki AI-assisted analysis of the OpenTitan codebase was used as a cross-check during manual inspection.

LLM

Yes - DeepWiki (LLM-based repository analysis), used as a detection aid.

LLM Details

PLACEHOLDER - to be completed (model name/version, parameters, download link or API endpoint).

Online LLM Details

PLACEHOLDER - to be completed (input/output/total token counts, verification script).

LLM Prompts

PLACEHOLDER - to be completed (complete prompt, full model response, step-by-step explanation).

Detection method

Manual RTL inspection of chiplevel.sv.tpl for illegal hardwired constants, cross-checked with DeepWiki, and proven end-to-end on the full Darjeeling SoC: a main-core OTTF test (bug8_ctn_exploit.c) issues a raw access through the CTN window (0x40000000) to the secure-island CTN SRAM (0x41000000), writes marker 0xBADC8008 and reads it back. The correct range check would squash this out-of-range request; under the planted overwrite the access is granted and the marker reads back intact (see exploit/logs/full-soc-run.log: EXPLOIT SUCCESSFUL - PASS! - SW TEST PASSED - TEST PASSED CHECKS, dvsim P:1 100%).

Security impact

The Darjeeling variant is a “Secure Island” for larger SoCs; the CTN interface is the primary security boundary for external accesses. Permanently disabling address-range checks defeats the RACL system - any external CTN request can access any address range without restriction, exposing the secure island’s memories and peripherals to the main SoC.

Adversary profile

Unprivileged software on the main SoC (Type 1), or a network-side entity able to issue CTN transactions (interface is exposed at the SoC proxy). No physical access required.

Proposed mitigation

Remove the hardwired assignment; connect ac_range_check_overwrite_i to a configurable source (OTP / lifecycle controller / register) and ensure the default is MuBi8False in production configurations.

CVSSv3.1 score and severity

8.2 - HIGH

CVSSv3.1 Details

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

Located in this repository (GitHub is the cloud storage for the submission):