CVE-2025-32463

CVE-2025-32463 Sudo Chroot LPE Mitigation

Sudo 1.9.14–1.9.17 resolves NSS from inside an attacker-controlled chroot, executing a malicious shared library as root before any sudoers check. Watch the bare exploit, then the same exploit blocked by agentsh's three-layer policy.

Sudo CVE Advisory → Install agentsh → Canyon Road →
Policy

How agentsh blocks it

Three independent enforcement layers. Any one is sufficient to prevent the exploit. The attacker must bypass all three simultaneously — which is impossible from within the session.

1 Deny shared-object writes under agent paths file_rules · policy.yml
CVE-2025-32463 works by planting a malicious .so where sudo -R will load it via NSS. This rule blocks writing, creating, renaming, or chmod-ing any shared library under /workspace (the agent's virtualised home) or /tmp. The exploit dies at the compilation step — before sudo ever runs. 
file_rules:
  - name: no_so_from_user_paths
    paths:
      - "/workspace/**/*.so"
      - "/workspace/**/*.so.*"
      - "/tmp/**/*.so"
      - "/tmp/**/*.so.*"
    operations: [write, create, rename, chmod]
    decision: deny
    message: "Shared object under agent workspace or /tmp denied"
if bypassed, next layer catches it
2 Deny sudo -R / --chroot at exec time command_rules · policy.yml
Inspects argv before execve(2). If any process runs sudo with -R, --chroot, or -D — the flags that trigger the vulnerable code path — the call is denied before the binary ever launches. Even if the attacker manages to plant their .so, this rule prevents the trigger. 
command_rules:
  - name: no_sudo_chroot
    commands: [sudo]
    args_patterns:
      - '(^|\s)-R(\s|$)'
      - '(^|\s)--chroot(\s|=)'
      - '(^|\s)-D(\s|=)'
    decision: deny
    message: "sudo -R/--chroot blocked (CVE-2025-32463)"
if bypassed, the kernel enforces the floor
3 Block chroot(2) at the kernel boundary sandbox.seccomp · config.yml
At the seccomp layer, the chroot syscall returns EPERM for every process in the session. This catches the primitive even if the attacker uses a binary not named in command_rules. Crucially, this rule cannot be overridden by editing policy.yml — it lives in the daemon config, which the agent session has no ability to modify. 
# config.yml (daemon-wide — not in policy.yml)
sandbox:
  seccomp:
    enabled: true
    mode: enforce
    syscalls:
      default_action: allow
      block: [chroot]
      on_block: errno
Before

Bare exploit — no agentsh

alice triggers CVE-2025-32463. The malicious .so constructor fires as root (euid=0) before any sudoers check. The marker file /tmp/OWNED-BY-ALICE is written—exploit succeeded.

VERDICT: EXPLOIT SUCCEEDED
After

Same exploit under agentsh

Three-layer policy: file rules block the .so drop, command rules block sudo -R, seccomp blocks chroot(2) at the kernel boundary. The marker never appears—exploit blocked.

VERDICT: BLOCKED
Configuration mitigation

agentsh configuration mitigation

Current agentsh builds do not ship a built-in mitigation_sets entry for CVE-2025-32463. Add the policy-layer rules to the session policy and keep the syscall block in the daemon configuration. The policy denies the NSS payload staging path and the vulnerable sudo -R trigger; the daemon config blocks chroot(2) for every supervised process.

1 Add to policy.yml file_rules + command_rules
These rules stop shared-object payload writes in agent-controlled paths and deny sudo executions that request the vulnerable chroot mode. 
file_rules:
  - name: no_so_from_user_paths
    paths:
      - "/workspace/**/*.so"
      - "/workspace/**/*.so.*"
      - "/tmp/**/*.so"
      - "/tmp/**/*.so.*"
    operations: [write, create, rename, chmod]
    decision: deny
    message: "Shared object under agent workspace or /tmp denied"

command_rules:
  - name: no_sudo_chroot
    commands: [sudo]
    args_patterns:
      - '(^|\s)-R(\s|$)'
      - '(^|\s)--chroot(\s|=)'
      - '(^|\s)-D(\s|=)'
    decision: deny
    message: "sudo -R/--chroot blocked (CVE-2025-32463)"
2 Add to daemon config.yml sandbox.seccomp
This daemon-wide rule blocks the underlying syscall even if an attacker reaches it through a binary or argument pattern that the policy rules did not name. 
sandbox:
  seccomp:
    enabled: true
    mode: enforce
    syscalls:
      default_action: allow
      block: [chroot]
      on_block: errno