DF-0473 — Out-of-bounds indirect function call in ip_fw3_chk (CWE-129/787)

ip_fw3_chk (sys/net/ipfw3/ip_fw3.c:506-507) indexes filter_funcs[cmd->module][cmd->opcode] — a [10][100] (1000-entry) array — with attacker-controlled uint8_t module/opcode that are never bounds-checked. A crafted rule with module>=10 or opcode>=100 reads an arbitrary kernel pointer and calls it => wild call => kernel panic (trap 9).

Files

• oobcall.c — main trigger: install OOB-index rule (cmd_len=2), enable firewall, send packet -> panic.
• add_oob.c — install-only test (safe on unpatched: no firewall enable).
• add_legit.c — regression test (legitimate rule must still install).
• nullcall.c — exercises the call-site NULL check (in-range/unregistered opcode).
• build.sh / run.sh — exact build/run.
• fix.diff — two-hunk fix (call-site bounds+NULL check + install-time range validation).
• VERDICT.md — full analysis + before/after fix validation.
• panic.txt / run.log / fix_run.log / fix_build.log / env.txt — evidence.

Build

cc -Wall -o oobcall   oobcall.c
cc -Wall -o add_oob   add_oob.c
cc -Wall -o add_legit add_legit.c
cc -Wall -o nullcall  nullcall.c

Run (ROOT only — raw socket + ipfw3 ctl path)

kldload ipfw3
sysctl net.inet.ip.fw3.enable=0
./oobcall            # UNPATCHED: kernel panic at ip_fw3_chk+0x1a4

Expected (bug present): rc=0 on the rule add, then the firewall is enabled and the guest panics on the next evaluated packet with Fatal trap 9 ... Stopped at ip_fw3_chk+0x1a4: ret. (ssh dies; panic is in dfbsd-qemu/boot.log.)

Preconditions / threat model (honest)

• Root-only trigger. The rule-add path (IP_FW_X/IP_FW_ADD) needs a raw socket (root) and the ipfw3 KLD module loaded. No unprivileged-user privilege boundary is crossed; the value is the kernel memory-corruption primitive (CWE-129 OOB indirect call / CWE-787 wild call), not LPE.
• Distinct from DF-0472. This PoC installs a correctly-sized rule (cmd_len=2, full data), so it survives DF-0472's cmd_len fix — DF-0473 is an independent defect requiring its own call-site/install-time fix.

Fix

fix.diff (two hunks): 1. Call-site (ip_fw3.c:506): bounds-check module < MAX_MODULE && opcode < MAX_OPCODE_PER_MODULE and NULL-check the function pointer; on failure skip the instruction (goto next_cmd). 2. Install-time (ip_fw3_ctl_add_rule, :979): walk the rule's instructions and return EINVAL if any has an out-of-range module/opcode.

After hot-swapping the patched ipfw3.ko: OOB rule add => EINVAL, no panic; legitimate rules still accepted (rc=0).

DF-0473 — Verdict

Verdict: REPRODUCED (OOB indirect function call -> kernel panic). FIX VALIDATED.

The bug

ip_fw3_chk (sys/net/ipfw3/ip_fw3.c:506-507) evaluates a firewall rule's instructions and, for each, performs an indirect call:

(filter_funcs[cmd->module][cmd->opcode])
    (&cmd_ctl, &cmd_val, &args, &f, cmd, ip_len);

filter_funcs is declared at ip_fw3.c:163 as

filter_func filter_funcs[MAX_MODULE][MAX_OPCODE_PER_MODULE];

with MAX_MODULE = 10 and MAX_OPCODE_PER_MODULE = 100 (ip_fw3.h:94) — a 1000-entry array. cmd->module and cmd->opcode are uint8_t (range 0..255) taken verbatim from the rule (ipfw_insn, ip_fw3.h:124-132) and are never bounds-checked anywhere:

• the rule-add path ip_fw3_ctl_add_rule (ip_fw3.c:951) validates only the total sopt_valsize ([sizeof(ioc_rule)-sizeof(ipfw_insn) .. 1020], :956-957), never the per-instruction module/opcode;
• the eval loop (:493-507) indexes the array directly.

A rule whose instruction carries module >= 10 or opcode >= 100 therefore indexes past the 1000-entry array, reads an arbitrary kernel pointer, and calls it. With module=0x80 opcode=0x80 the index is 0x80*100 + 0x80 = 12928, i.e. 12828 entries past the array — deep into neighbouring kernel data (the fw3_modules/fw3_ctx/fw3_sync_ctx globals and beyond).

Distinctness from DF-0472

DF-0472 was the missing cmd_len validation: it fed garbage into the rule via a cmd_len=255 over-read. DF-0473 is a separate, independent bug: the OOB module/opcode index use. This PoC proves it by installing a correctly-sized rule (cmd_len=2, one 8-byte instruction, act_ofs=0, full data supplied) whose single instruction explicitly carries module=0x80 opcode=0x80. This rule passes DF-0472's cmd_len validation (size=48 ∈ [32,1020], cmd_len=2, act_ofs=0 < cmd_len, full data present) yet still triggers the OOB call. DF-0473 therefore survives a complete fix for DF-0472 and must be fixed independently at the call site (and/or the install path).

Mechanism (every hop cited)

• Trigger (root): socket(AF_INET, SOCK_RAW, IPPROTO_RAW) → setsockopt(IPPROTO_IP, IP_FW_X=49, [x_hdr.opcode=IP_FW_ADD=50][ioc_rule], 48) (in.h:389). raw_ip.c rip_ctloutput → ip_fw3_sockopt (ip_fw3_glue.c) → ip_fw3_ctl_x (ip_fw3.c:1038) strips the 4-byte x_header → ip_fw3_ctl → ip_fw3_ctl_sockopt (:1138) case IP_FW_ADD → ip_fw3_ctl_add_rule (:951).
• No per-instruction validation (:956-979): only sopt_valsize and (with DF-0472's fix) cmd_len/act_ofs/size are checked; module/ opcode of every instruction are copied verbatim into the rule by add_rule_dispatch (:655, bcopy(ioc_rule->cmd, rule->cmd, cmd_len*4)).
• OOB indirect call (:506): when the firewall is enabled and a packet is evaluated, ip_fw3_chk walks the rule and calls (filter_funcs[cmd->module][cmd->opcode])(...). Attacker module=0x80, opcode=0x80 indexes entry 12928 of the 1000-entry array → wild pointer call → kernel panic.

Evidence

OOB-call panic (trap 9)

./oobcall on the unpatched #0 module installs the OOB-index rule (rc=0), enables the firewall, and the guest panics on the next evaluated packet (full signature in panic.txt):

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; lapic id = 0
instruction pointer     = 0x8:0xffffffff826001a4
current process         = Idle
Stopped at      ip_fw3_chk+0x1a4:       ret

RIP 0xffffffff826001a4 = ipfw3.ko base (0xffffffff82600000) + 0x1a4, symbolised by ddb as ip_fw3_chk+0x1a4 — the filter_funcs[module][opcode] indirect-call site (:506). The wild call ran a few instructions off the corrupted pointer and faulted on ret.

Impact (honest)

• Root-only trigger. The rule-add path needs a raw socket (root) and the ipfw3 KLD module loaded. No unprivileged-user privilege boundary is crossed; the value is the kernel memory-corruption primitive (CWE-129 OOB indirect call / CWE-787 wild call), not LPE. Relevance: compromised root process, a setuid ipfw3 front-end, jail escape.
• Primitive characterisation. On this guest SMEP/SMAP/KASLR are OFF, so a heap-grooming chain that lands a chosen value at filter_funcs[0x80][0x80] would redirect the call to userspace shellcode (commit_creds(prepare_kernel_cred(0))) for root→kernel code execution; demonstrated here at the panic (DoS) level. Because the trigger is already root, an LPE chain is moot — the deliverable is the memory-corruption primitive itself.

The fix (fix.diff) — two defense-in-depth hunks

Hunk 1 (root cause, what the finding recommends): call-site bounds + NULL check at ip_fw3.c:506. Before the indirect call, verify cmd->module < MAX_MODULE && cmd->opcode < MAX_OPCODE_PER_MODULE and that filter_funcs[cmd->module][cmd->opcode] != NULL; if any fails, set cmd_val = 0 and goto next_cmd (skip the instruction, treat as non-match). This is the last line of defence: it catches OOB/unregistered opcodes from any source (a crafted rule, the DF-0472 over-read path, future bugs, or corrupted memory).

Hunk 2 (defense-in-depth, front door): install-time range validation in ip_fw3_ctl_add_rule (ip_fw3.c:979). Walk every instruction of the candidate rule using the same F_LEN() stepping as ip_fw3_chk and return EINVAL if any instruction has module >= MAX_MODULE or opcode >= MAX_OPCODE_PER_MODULE. This rejects the malicious rule before it is ever installed.

Both hunks are minimal and targeted; a legitimate rule (module=0 BASIC, opcode=0 ACCEPT) is still accepted (verified: rc=0, no regression).

This fix supplements (does not conflict with) DF-0472's cmd_len fix — the two address orthogonal defects in the same two functions.

Fix validation (Phase 8)

ipfw3 is a loadable module, so the fix was validated by rebuilding only ipfw3.ko (make KERNBUILDDIR=.../X86_64_GENERIC in sys/net/ipfw3, -Werror, rc=0) and hot-swapping it (kldunload/cp/kldload); no kernel rebuild/reboot required.

Clean before/after: the bad behaviour (OOB rule accepted + panic) is present on the unpatched #0 module and gone on the single-fix module, with legitimate rules unaffected and both hunks independently exercised. fix_status = fixed.

Reproduce

cd findings/poc/DF-0473
./build.sh            # cc -Wall -o oobcall oobcall.c (+ add_oob, add_legit, nullcall)
# as root, on the guest:
kldload ipfw3
sysctl net.inet.ip.fw3.enable=0
./oobcall             # UNPATCHED: kernel panic at ip_fw3_chk+0x1a4
# after applying fix.diff + hot-swapping ipfw3.ko:
./oobcall             # PATCHED: add rejected EINVAL, no panic
./add_legit           # PATCHED: legit rule still accepted (rc=0)