Linux kernel use-after-free in Netfilter, local privilege escalation

Post by galangalalgol » Wed, May 10, 2023, 12:33 AM UTC

veonik wrote: post #19

pizzalife wrote: post #10

Earlier quoted context omitted.

> but the specific module in question in the patch, nf_tables, is not loaded on my Ubuntu 20.04LTS 5.40 kernel running iptables/ufw at least This doesn't matter since Linux has autoloading of most network modules, and you can cause the modules to be loaded on Ubuntu since it supports unprivileged user/net namespaces. ubuntu:~% grep DISTRIB_DESCRIPTION /etc/lsb-release DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS" ubuntu:~…

Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?

Post by eklitzke » Wed, May 10, 2023, 12:42 AM UTC

fnordpiglet wrote: post #22

Rust needs to be more prominent in the kernel, and where not rust ebpf. The days of hand mangling pointer arithmetic need to end.

Post by eklitzke » Wed, May 10, 2023, 12:53 AM UTC

wtallis wrote: post #24

eklitzke wrote: post #23

Earlier quoted context omitted.

The patch doesn't fix anything with pointer arithmetic: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

I wouldn't generally expect a use-after-free to result from improper pointer arithmetic; that's the recipe for a buffer overflow. But Rust happens to also be well-known for helping manage object lifetimes, which seems to be what went wrong here.

  priv->set->use++;

  nf_tables_activate_set(ctx, priv->set);

  void nf_tables_activate_set(const struct nft_ctx *ctx, struct nft_set *set) {
    if (nft_set_is_anonymous(set))
      nft_clear(ctx->net, set);
    set->use++;
  }

Post by sp332 » Wed, May 10, 2023, 1:04 AM UTC

hsbauauvhabzb wrote: post #14

l33tman wrote: post #8

"We developed an exploit that allows unprivileged local users to start a root shell by abusing the above issue. That exploit was shared privately with to assist with fix development. Somebody from the Linux kernel team then emailed the proposed fix to and that email also included a link to download our description of exploitation techniques and our exploit source code. Therefore, according to the linux-distros list p…

What’s actually reasonable here. I’m all for exploit code becoming public eventually, but I think it’s silly to drop it immediately after a fix has been released, or before, in almost all scenarios (unless there’s been 90+ days or the issue marked as wontfix)

Post by unixhero » Wed, May 10, 2023, 1:16 AM UTC

snvzz wrote: post #28

There's easily thousands of such bugs hidden in the kernel. Reminder the kernel has over ten million LoCs, or megabytes of object code. Perhaps we should start thinking about whether it is a good idea to run something this large in supervisor mode, with full privileges. I wouldn't say it is sensible in a world where seL4 exists.