6 ms·

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

288 points by kuizu 3y ago

alex14fr 3y ago
Glad to have sticked with the good old iptables and left CONFIG_NF_TABLES unset in kernel configuration.
- sam_lowry_ 3y ago
  Aren't iptables just an emulation layer on top of netfilter?
  - eikenberry 3y ago
    Probably depends on the distro. Iptables is a wrapper around nftables in most distros, but probably not all.
    - smashed 3y ago
      You can check with: iptables -V If it says (nf_tables), you are using the compatibility layer from the iptables-nft package. It works quite well. Apps like Docker that inserts rules using the legacy iptables syntax are oblivious to the fact that they are actually inserting nftables rules. It also provides an easy migration path. Insert your old rules using your iptables script then list them in the new syntax using nft list ruleset. The problem is that it works so well that it seems most users just stayed with the iptables syntax and did not bother migrating at all.
      - ahartmetz 3y ago
        IMO, the problem is that the people who created nftables (and the "ip" tool) couldn't create a user interface that anyone but themselves would like to use. Linux traffic shaping functionality suffers from the same "obscure word soup" interface.
        smashed 3y ago
        I agree for the "ip" tool (from iproute2).. I got used to it but I still prefer the ifconfig output. It is somehow consistant and you can get used to it. I somehow got accustomed to the nftables rules format. It is in fact objectively much better than the iptables format in many ways. The native JSON, easy bulk submit to the kernel, built-in sets and maps (the source of the currently discussed CVE though). It really does fix a lot of what was wrong with iptables. But iptables was probably not broken enough for most users to warrant re-learning everything. Now, the traffic shaping tool, oof.. I still cannot grok any of it. I've been happy with the fireqos script so far to abstract everything out of the tc syntax.
  - TechBro8615 3y ago
    Yes, AFAIU (not an expert), iptables and nftables are two command line tools and abstractions (chains vs. tables) for interacting with the same underlying netfilter API.
    - nubinetwork 3y ago
      I believe at one time they were two separate subsystems, but they got merged in 4.x or 5.x
      - alex14fr 3y ago
        I run 6.3 and the incriminated files were not compiled in my kernel thanks to CONFIG_NF_TABLES=n during make config.
  - failsecure 3y ago
    For modern distros, the nft package includes an alternative binary that takes the place of /sbin/iptables and translates the input to an nft compatible format. As far as the kernel is concerned, iptables is still iptables. Old iptables can be accessed by calling the iptables-legacy binary which will auto load the old iptables ko.
knorker 3y ago
> delete an existing nft rule that uses an nft anonymous set. And an example of the latter operation is an attempt to delete an element from that nft anonymous set after the set gets deleted I'd be very interested to hear how this can be done by an unprivileged user. Try to race set add/removals, sure, but if it depends on the set itself getting deleted, that seems… harder.
- 0x006A 3y ago
  on https://bugzilla.redhat.com/show_bug.cgi?id=2196105 https://bugzilla.redhat.com/show_bug.cgi?id=2196105 a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled
  - pizzalife 3y ago
    >a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled Which is the default on Ubuntu.
    - chlorion 3y ago
      It's the default on pretty much any modern Linux system!
      - klooney 3y ago
        From 2016- https://lwn.net/Articles/673597/ https://lwn.net/Articles/673597/ Andy Lutomirski described some concerns of his own: > I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over /any/ network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there.
        withinboredom 3y ago
        I hope he hasn't been eating his hat all these years. I hear that isn't good for the digestive system... /s
l33tman 3y ago
"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 <security () kernel org> to assist with fix development. Somebody from the Linux kernel team then emailed the proposed fix to <linux-distros () vs openwall org> 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 policy, the exploit must be published within 7 days from this advisory. In order to comply with that policy, I intend to publish both the description of exploitation techniques and also the exploit source code on Monday 15th by email to this list." Interesting.. they didn't write what conditions have to be met for it to be exploitable. Also interesting that someone screwed up and accidentally forwarded an email including the exploit to a broad mailing list... Part of the nf modules are active if you have iptables, which you have if you run ufw (for example), so pretty broad exploit if that's all that's required, 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.
- pizzalife 3y ago
  > 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:~% lsmod|grep nf_table ubuntu:~% unshare -U -m -n -r ubuntu:~% nft add table inet filter ubuntu:~% lsmod|grep nf_table nf_tables 249856 0
  - veonik 3y ago
    Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?
    - touisteur 3y ago
      Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something? Edit: should've read better, this seems to need CLONE_NEWUSER.
fnordpiglet 3y ago
[flagged]
AdamJacobMuller 3y ago
https://nvd.nist.gov/vuln/detail/CVE-2023-32233 https://nvd.nist.gov/vuln/detail/CVE-2023-32233 The NIST CVE page points back here. Funny. Nothing I see so far specifically says how far back this goes, but, https://security-tracker.debian.org/tracker/CVE-2023-32233 https://security-tracker.debian.org/tracker/CVE-2023-32233 Seems to go back really far.
fnordpiglet 3y ago
Rust needs to be more prominent in the kernel, and where not rust ebpf. The days of hand mangling pointer arithmetic need to end.
- eklitzke 3y ago
  The patch doesn't fix anything with pointer arithmetic: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=c1592a89942e9678f7d9c8030efa777c0d57edab https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - wtallis 3y ago
    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.
    - eklitzke 3y ago
      I'm not sure if your claim here is correct. The patch is to change call sites like priv->set->use++; To look like: nf_tables_activate_set(ctx, priv->set); Where this function is defined as: 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++; } So to me (someone who is not an expert in this code) it looks like the fix is checking if the set has the anonymous flag before changing the reference count. I'm not an expert in this code and I could be mistaken, but I think your claim that this would be fixed by Rust object lifetime checking requires better evidence.
      - hornd 3y ago
        [dead]
      - comex 3y ago
        One of the parts of Rust’s safety story is to always use smart pointers for reference counting rather than the type of ad-hoc manual reference count management seen in the code you quoted. Combined with lifetime checking, it makes it impossible for some random logic error to cause a use-after-free.
snvzz 3y ago
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.
- userbinator 3y ago
  Alternatively, perhaps we should start thinking about whether it is a good idea to have multiple users of different privilege sharing the same hardware.
  - thfuran 3y ago
    What's the alternative, just running all code at ring 0?
    - Aerbil313 3y ago
      https://www.theseus-os.com/ https://www.theseus-os.com/
    - userbinator 3y ago
      IMHO rings 0 + 3 with protections against bugs, and not deliberate malice, is probably the sweet spot.
  - deleted 3y ago
    [deleted]
  - travis729 3y ago
    I’ve been thinking this recently as well.
  - gizmo686 3y ago
    "User" in a modern Linux system is just a weird name for "security domain". Many programs run as their own user to limit their ability to attack the rest of the system if they get compromised; and limit the ability of a different compromised component from attacking them. My desktop, on which I am the only person with an account, has 49 "users", of which 11 are actively running a process. At work, every daemon we run has a dedicated user. On android, every app runs as its own user.
explorer83 3y ago
Based on this 11 month old discussion this has been an exploit vector for sometime - https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3DR5w https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3... "I vaguely recall at least around 6-7 such holes, and a quick google search seems to reveal that at least those would have been mitigated by unprivileged user namespaces being disabled: CVE-2019-18198 CVE-2020-14386 CVE-2022-0185 CVE-2022-24122 CVE-2022-25636 CVE-2022-1966 resp. CVE-2022-32250"
moring 3y ago
Honest question: Why did they build an exploit that uses the bug? I always assumed that use-after-free is equivalent to "game over" (i.e. I assumed that local privilege escalation is a given) and it is clear that such a bug must be fixed. By that I mean, it might be easy or hard to exploit a bug to achieve LPE, but it seems to be redundant to prove that it is possible.
- mort96 3y ago
  Making a PoC is a great way to convince both yourself and the maintainers that the bug is actually exploitable in the wild and thus a big fucking deal. Alternatively, you might discover that there are some other things going on which turns out to make the bug unexploitable.
  - moring 3y ago
    Let me rephrase my question: Is there actually such a thing as an "unexploitable use-after-free"? How would that look like? How would you reason that it is actually unexploitable? Context: My experience with C programming is that practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.
    - friendzis 3y ago
      > How would that look like? How would you reason that it is actually unexploitable? For use-after-free to be exploitable, by definition an attacker must be able to put arbitrary content at the memory region. This is not always easy: may require certain [mis]configuration, data layout and so on. > practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible. I will not contest this claim, however there is a difference between "blow up" and "exploit". Malicious packet being able to segfault a server is one thing, malicious packet resulting in RCE is quite another. This may be a lost in translation moment when under colloquial use "exploit" does not include DoS.
    - mort96 3y ago
igo95862 3y ago
I am developing a sandbox project for Linux desktop applications called bubblejail: https://github.com/igo95862/bubblejail https://github.com/igo95862/bubblejail In the next not yet released version 0.8.0 there will be a new option to disable a specific namespace type per sandbox. For example, disabling the network namespace would prevent this exploit. This is more flexible than globally disabling all user namespaces as some programs might use other more harmless namespaces like Steam uses mount namespaces to setup runtime libraries.
theooyuan 3y ago
[dead]

288 points by kuizu 3y ago

alex14fr 3y ago

Glad to have sticked with the good old iptables and left CONFIG_NF_TABLES unset in kernel configuration.

sam_lowry_ 3y ago
Aren't iptables just an emulation layer on top of netfilter?
- eikenberry 3y ago
  Probably depends on the distro. Iptables is a wrapper around nftables in most distros, but probably not all.
  - smashed 3y ago
    You can check with: iptables -V If it says (nf_tables), you are using the compatibility layer from the iptables-nft package. It works quite well. Apps like Docker that inserts rules using the legacy iptables syntax are oblivious to the fact that they are actually inserting nftables rules. It also provides an easy migration path. Insert your old rules using your iptables script then list them in the new syntax using nft list ruleset. The problem is that it works so well that it seems most users just stayed with the iptables syntax and did not bother migrating at all.
    - ahartmetz 3y ago
      IMO, the problem is that the people who created nftables (and the "ip" tool) couldn't create a user interface that anyone but themselves would like to use. Linux traffic shaping functionality suffers from the same "obscure word soup" interface.
      - smashed 3y ago
        I agree for the "ip" tool (from iproute2).. I got used to it but I still prefer the ifconfig output. It is somehow consistant and you can get used to it. I somehow got accustomed to the nftables rules format. It is in fact objectively much better than the iptables format in many ways. The native JSON, easy bulk submit to the kernel, built-in sets and maps (the source of the currently discussed CVE though). It really does fix a lot of what was wrong with iptables. But iptables was probably not broken enough for most users to warrant re-learning everything. Now, the traffic shaping tool, oof.. I still cannot grok any of it. I've been happy with the fireqos script so far to abstract everything out of the tc syntax.
- TechBro8615 3y ago
  Yes, AFAIU (not an expert), iptables and nftables are two command line tools and abstractions (chains vs. tables) for interacting with the same underlying netfilter API.
  - nubinetwork 3y ago
    I believe at one time they were two separate subsystems, but they got merged in 4.x or 5.x
    - alex14fr 3y ago
      I run 6.3 and the incriminated files were not compiled in my kernel thanks to CONFIG_NF_TABLES=n during make config.
- failsecure 3y ago
  For modern distros, the nft package includes an alternative binary that takes the place of /sbin/iptables and translates the input to an nft compatible format. As far as the kernel is concerned, iptables is still iptables. Old iptables can be accessed by calling the iptables-legacy binary which will auto load the old iptables ko.

knorker 3y ago

> delete an existing nft rule that uses an nft anonymous set. And an example of the latter operation is an attempt to delete an element from that nft anonymous set after the set gets deleted I'd be very interested to hear how this can be done by an unprivileged user. Try to race set add/removals, sure, but if it depends on the set itself getting deleted, that seems… harder.

0x006A 3y ago
on https://bugzilla.redhat.com/show_bug.cgi?id=2196105 https://bugzilla.redhat.com/show_bug.cgi?id=2196105 a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled
- pizzalife 3y ago
  >a comment suggests that it might only be possible if you have "unprivileged user namespaces" enabled Which is the default on Ubuntu.
  - chlorion 3y ago
    It's the default on pretty much any modern Linux system!
    - klooney 3y ago
      From 2016- https://lwn.net/Articles/673597/ https://lwn.net/Articles/673597/ Andy Lutomirski described some concerns of his own: > I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over /any/ network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there.
      - withinboredom 3y ago
        I hope he hasn't been eating his hat all these years. I hear that isn't good for the digestive system... /s

l33tman 3y ago

"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 <security () kernel org> to assist with fix development. Somebody from the Linux kernel team then emailed the proposed fix to <linux-distros () vs openwall org> 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 policy, the exploit must be published within 7 days from this advisory. In order to comply with that policy, I intend to publish both the description of exploitation techniques and also the exploit source code on Monday 15th by email to this list." Interesting.. they didn't write what conditions have to be met for it to be exploitable. Also interesting that someone screwed up and accidentally forwarded an email including the exploit to a broad mailing list... Part of the nf modules are active if you have iptables, which you have if you run ufw (for example), so pretty broad exploit if that's all that's required, 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.

pizzalife 3y ago
> 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:~% lsmod|grep nf_table ubuntu:~% unshare -U -m -n -r ubuntu:~% nft add table inet filter ubuntu:~% lsmod|grep nf_table nf_tables 249856 0
- veonik 3y ago
  Yikes... are other popular distros shipping with unprivileged user namespaces enabled by default?
  - touisteur 3y ago
    Do you need a user namespace? I'd expect a network namespace to be enough. Am I missing something? Edit: should've read better, this seems to need CLONE_NEWUSER.

fnordpiglet 3y ago

[flagged]

AdamJacobMuller 3y ago

https://nvd.nist.gov/vuln/detail/CVE-2023-32233 https://nvd.nist.gov/vuln/detail/CVE-2023-32233 The NIST CVE page points back here. Funny. Nothing I see so far specifically says how far back this goes, but, https://security-tracker.debian.org/tracker/CVE-2023-32233 https://security-tracker.debian.org/tracker/CVE-2023-32233 Seems to go back really far.

fnordpiglet 3y ago

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

eklitzke 3y ago
The patch doesn't fix anything with pointer arithmetic: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=c1592a89942e9678f7d9c8030efa777c0d57edab https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- wtallis 3y ago
  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.
  - eklitzke 3y ago
    I'm not sure if your claim here is correct. The patch is to change call sites like priv->set->use++; To look like: nf_tables_activate_set(ctx, priv->set); Where this function is defined as: 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++; } So to me (someone who is not an expert in this code) it looks like the fix is checking if the set has the anonymous flag before changing the reference count. I'm not an expert in this code and I could be mistaken, but I think your claim that this would be fixed by Rust object lifetime checking requires better evidence.
    - hornd 3y ago
      [dead]
    - comex 3y ago
      One of the parts of Rust’s safety story is to always use smart pointers for reference counting rather than the type of ad-hoc manual reference count management seen in the code you quoted. Combined with lifetime checking, it makes it impossible for some random logic error to cause a use-after-free.

snvzz 3y ago

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.

userbinator 3y ago
Alternatively, perhaps we should start thinking about whether it is a good idea to have multiple users of different privilege sharing the same hardware.
- thfuran 3y ago
  What's the alternative, just running all code at ring 0?
  - Aerbil313 3y ago
    https://www.theseus-os.com/ https://www.theseus-os.com/
  - userbinator 3y ago
    IMHO rings 0 + 3 with protections against bugs, and not deliberate malice, is probably the sweet spot.
- deleted 3y ago
  [deleted]
- travis729 3y ago
  I’ve been thinking this recently as well.
- gizmo686 3y ago
  "User" in a modern Linux system is just a weird name for "security domain". Many programs run as their own user to limit their ability to attack the rest of the system if they get compromised; and limit the ability of a different compromised component from attacking them. My desktop, on which I am the only person with an account, has 49 "users", of which 11 are actively running a process. At work, every daemon we run has a dedicated user. On android, every app runs as its own user.

explorer83 3y ago

Based on this 11 month old discussion this has been an exploit vector for sometime - https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3DR5w https://groups.google.com/g/linux.debian.bugs.dist/c/ZF9rWY3... "I vaguely recall at least around 6-7 such holes, and a quick google search seems to reveal that at least those would have been mitigated by unprivileged user namespaces being disabled: CVE-2019-18198 CVE-2020-14386 CVE-2022-0185 CVE-2022-24122 CVE-2022-25636 CVE-2022-1966 resp. CVE-2022-32250"

moring 3y ago

Honest question: Why did they build an exploit that uses the bug? I always assumed that use-after-free is equivalent to "game over" (i.e. I assumed that local privilege escalation is a given) and it is clear that such a bug must be fixed. By that I mean, it might be easy or hard to exploit a bug to achieve LPE, but it seems to be redundant to prove that it is possible.

mort96 3y ago
Making a PoC is a great way to convince both yourself and the maintainers that the bug is actually exploitable in the wild and thus a big fucking deal. Alternatively, you might discover that there are some other things going on which turns out to make the bug unexploitable.
- moring 3y ago
  Let me rephrase my question: Is there actually such a thing as an "unexploitable use-after-free"? How would that look like? How would you reason that it is actually unexploitable? Context: My experience with C programming is that practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible.
  - friendzis 3y ago
    > How would that look like? How would you reason that it is actually unexploitable? For use-after-free to be exploitable, by definition an attacker must be able to put arbitrary content at the memory region. This is not always easy: may require certain [mis]configuration, data layout and so on. > practically every bug that is related to memory management tends to blow up right into your face, at the most inconvenient time possible. I will not contest this claim, however there is a difference between "blow up" and "exploit". Malicious packet being able to segfault a server is one thing, malicious packet resulting in RCE is quite another. This may be a lost in translation moment when under colloquial use "exploit" does not include DoS.
  - mort96 3y ago

igo95862 3y ago

I am developing a sandbox project for Linux desktop applications called bubblejail: https://github.com/igo95862/bubblejail https://github.com/igo95862/bubblejail In the next not yet released version 0.8.0 there will be a new option to disable a specific namespace type per sandbox. For example, disabling the network namespace would prevent this exploit. This is more flexible than globally disabling all user namespaces as some programs might use other more harmless namespaces like Steam uses mount namespaces to setup runtime libraries.

theooyuan 3y ago

[dead]