On Fri, Sep 13, 2024 at 05:07:46PM GMT, Maxwell Bland wrote:
> These programs will not print out using PTRACE and are difficult to audit
> without patching the seccomp calls yourself because the ptrace call to
> PTRACE_SECCOMP_GET_FILTER will fail. I believe (have not checked) because they
> are not cBPF, and seccomp's logic makes prog->fprog evaluates to null despite
> prog existing if it is cBPF, at least on Android 14. I spent a whole day
> getting frustrated with the failing ptrace call before finally ending up my
> patches (attached to the end) that instrument ptrace and can print the
> programs.
LOL, this paragraph is a mess, apologies: I'm referencing the failure of
get_seccomp_filter in seccomp.c here:
fprog = filter->prog->orig_prog;
if (!fprog) {
/* This must be a new non-cBPF filter, since we save
* every cBPF filter's orig_prog above when
* CONFIG_CHECKPOINT_RESTORE is enabled.
*/
ret = -EMEDIUMTYPE;
goto out;
}
Though CONFIG_CHECKPOINT_RESTORE is not set on Android 14, so I think
the ptrace probably failed for all sorts of reasons unrelated to cBPF.
But don't let me distract from the issue, which is that
cBPF/eBPF/however these filters get allocated to machine code,
bpf_int_jit_compile ends up getting called and a new
privileged-executable page gets allocated without compile-time
provenance (at least, without reverse engineering) for where that code
came from.
But I think instrumentation of the BPF JIT compiler (which I will work
on next) should fix that.
