Bug 2196105 (CVE-2023-32233)
| Summary: | CVE-2023-32233 kernel: netfilter: use-after-free in nf_tables when processing batch requests can lead to privilege escalation | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Rohit Keshri <rkeshri> |
| Component: | vulnerability | Assignee: | Nobody <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | acaringi, admin-team, allarkin, anyonearomatic, arcadiy, bartlomiej, bglick, bhu, boboshaq, chaekim, chwhite, crwood, dbohanno, ddepaula, debarbos, dfreiber, dseok, dvlasenk, egarver, ezulian, fankymobile, fwestpha, hkrzesin, jaeshin, jarod, jburrell, jdenham, jfaracco, jferlan, jforbes, j.k.moore+redhat, jlelli, joe.lawrence, jpoimboe, jshortt, jstancek, jwyatt, kcarcia, kernel-mgr, kpatch-maint-bot, kyoshida, ldoskova, lgoncalv, lleshchi, lzampier, mvanderw, nmurray, pdwyer, ptalbert, qzhao, reerror, rhandlin, rik.theys, rogbas, rrobaina, rvrbovsk, rysulliv, scweaver, spam+redhat, steven, sukulkar, tdamato, tru, tyberry, vkumar, walters, wbachman, wcosta, williams, wmealing, ycote, youssef.ghorbal |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel 6.4-rc1 | Doc Type: | If docs needed, set a value |
| Doc Text: |
A use-after-free vulnerability was found in the Netfilter subsystem of the Linux kernel when processing batch requests to update nf_tables configuration. This vulnerability can be abused to perform arbitrary reads and writes in kernel memory. A local user (with CAP_NET_ADMIN capability) could use this flaw to crash the system or potentially escalate their privileges on the system.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2196131, 2196132, 2196133, 2196134, 2196135, 2196136, 2196137, 2196138, 2196139, 2196140, 2196141, 2196142, 2196143, 2196144, 2196145, 2196146, 2196147, 2196148, 2196149, 2196150, 2196151, 2196152, 2196153, 2196154, 2196155, 2196156, 2196157, 2196158, 2196159, 2196160, 2196587, 2196588, 2196589, 2196590, 2196591, 2196592, 2196593, 2196594, 2196595 | ||
| Bug Blocks: | 2193200 | ||
|
Description
Rohit Keshri
2023-05-08 05:00:08 UTC
Reference: https://seclists.org/oss-sec/2023/q2/133 The issue says "[it] can be abused by unprivileged local users to escalate privileges" but aren't "unprivileged user namespaces" required to achieve this? A regular unprivileged local user cannot execute any "nft" commands. If we disable "unprivileged user namespaces" on the system, then this vulnerability cannot be exploited, right? In reply to comment #7: > Reference: https://seclists.org/oss-sec/2023/q2/133 > > The issue says "[it] can be abused by unprivileged local users to escalate > privileges" but aren't "unprivileged user namespaces" required to achieve > this? > > A regular unprivileged local user cannot execute any "nft" commands. If we > disable "unprivileged user namespaces" on the system, then this > vulnerability cannot be exploited, right? Hello Team, likely right, but better to disable overall the affected module if possible by blacklisting it. ~~~ How do I blacklist a kernel module to prevent it from loading automatically? https://access.redhat.com/solutions/41278 ~~~ (In reply to Rohit Keshri from comment #9) > In reply to comment #7: > > Reference: https://seclists.org/oss-sec/2023/q2/133 > > > > The issue says "[it] can be abused by unprivileged local users to escalate > > privileges" but aren't "unprivileged user namespaces" required to achieve > > this? > > > > A regular unprivileged local user cannot execute any "nft" commands. If we > > disable "unprivileged user namespaces" on the system, then this > > vulnerability cannot be exploited, right? > > Hello Team, likely right, but better to disable overall the affected module > if possible by blacklisting it. > ~~~ > How do I blacklist a kernel module to prevent it from loading automatically? > https://access.redhat.com/solutions/41278 > ~~~ Can you clarify which module you are talking about? And rationale? Seems ambiguity here may lead to improper functioning of firewall Hi all, I also do not understand what you mean by "disabling kernel module". If I disable "nf_tables", I will loose the ability to use firewall rules (as far as I understand)? From my opinion, this vulnerability only affects machines that have "max_user_namespaces" enabled (set to a greater value than zero (0) ): "The maximum number of user namespaces that any user in the current user namespace may create." Source: https://docs.kernel.org/admin-guide/sysctl/user.html#max-user-namespaces On el7 (CentOS, RHEL) the setting is set to 0 by default: [root@rhel7-test ~]# cat /proc/sys/user/max_user_namespaces 0 On el8 (CentOS, Alma, RHEL) the setting is set to 7094 by default: [root@rhel8-test ~]# cat /proc/sys/user/max_user_namespaces 7094 The mitigation attempt, provided by ubuntu.com, does not work under el7 machines: [root@rhel7-test ~]# sysctl -w kernel.unprivileged_userns_clone=0 sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory Source: https://ubuntu.com/security/CVE-2023-32233 It seems to me that the relation to user namespace cloning does not exist in el7: [root@rhel7-test ~]# cat /proc/sys/kernel/userns_restrict cat: /proc/sys/kernel/userns_restrict: No such file or directory Could someone please clarify what we have actually have to do here? Are my assumptions right or did I mentioned wrong things here? Cheers, Steven Hi folks, Given disabling user namespaces *seems* to be the sensible mitigation where the nf_tables kernel module cannot be blacklisted the following link may be of use: https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-12-03/finding/V-230548 I have verified the above steps do function on a RHEL 8 machine. Note: if containers are in use or user namespaces are essential for another reason, this mitigation is contraindicated. I highly advise testing on each type of application server in use to validate this does not cause problems prior to rolling out widely. Cheers, James. Hello Team, In order to mitigate this issue it is possible to prevent the affected code from being loaded by blacklisting the kernel module nf_tables. but it disables firewall. If cannot disable firewall, then use mitigation 2 instead (with namespaces). Thanks, do we have visibility on when fixes can be backported? Also, does it affect rootless container? Hi, When I set user.max_user_namespaces = 0 on my laptop:) witch Oracle Linux Server release 9.2, upower.service crashes: (code=exited, status=217/USER). Then I don't see status of load my battery and I don't have prompts to connect my charger when power is low. Computer is switching off in unexpected moment. When I set user.max_user_namespaces >= 1 service works as expected. Regards! (In reply to Steven from comment #12) > Could someone please clarify what we have actually have to do here? > Are my assumptions right or did I mentioned wrong things here? As James Moore indicates in comment 13, you're applying the wrong mitigations. You are applying Ubuntu/Debian mitigations to RedHat. The RedHat STIG outlines the needed changes, which involves a different sysctl flag. Hi, is there any available forecast on when fixes will be issued? The mitigation of disabling userns is not an option for us. Are we talking days or weeks? Thank you! Youssef Hello than you for reaching to us, yes I agree. We have accelerated this already, few of the fixes are already in phases or complete, rest are in the pipeline. Regarding rootless containers: A rootless container is just a container run in a separate user namespace, if the user in that user namespace has sufficient privileges (looks like CAP_NET_ADMIN), then I think they would be able to exploit the issue as well. This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2023:3349 https://access.redhat.com/errata/RHSA-2023:3349 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2023:3351 https://access.redhat.com/errata/RHSA-2023:3351 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2023:3350 https://access.redhat.com/errata/RHSA-2023:3350 Hello, thank you for the update ! Is there a plan to release an errata for 8.6 EUS ? Youssef What is el7's resolution schedule? This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Extended Update Support Via RHSA-2023:3470 https://access.redhat.com/errata/RHSA-2023:3470 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Extended Update Support Via RHSA-2023:3465 https://access.redhat.com/errata/RHSA-2023:3465 (SPAM link was here, deleted comment) This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Extended Update Support Via RHSA-2023:3490 https://access.redhat.com/errata/RHSA-2023:3490 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:3705 https://access.redhat.com/errata/RHSA-2023:3705 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:3708 https://access.redhat.com/errata/RHSA-2023:3708 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:3723 https://access.redhat.com/errata/RHSA-2023:3723 What is the status on this for RHEL 7 & RHEL 8.6 EUS? We've opened support tickets with Red Hat about this where they point us to this Bugzilla issue which gives no indication of timing or priority for this update from Red Hat. We've been waiting for this 'Important' security update almost 2 months. That does not seem to match the priorities that Red Hat has published about supported OS 'Important' security updates. This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions Via RHSA-2023:3853 https://access.redhat.com/errata/RHSA-2023:3853 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions Via RHSA-2023:3852 https://access.redhat.com/errata/RHSA-2023:3852 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Advanced Update Support Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions Red Hat Enterprise Linux 8.2 Telecommunications Update Service Via RHSA-2023:4125 https://access.redhat.com/errata/RHSA-2023:4125 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Telecommunications Update Service Via RHSA-2023:4126 https://access.redhat.com/errata/RHSA-2023:4126 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2023:4145 https://access.redhat.com/errata/RHSA-2023:4145 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2023:4130 https://access.redhat.com/errata/RHSA-2023:4130 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions Via RHSA-2023:4146 https://access.redhat.com/errata/RHSA-2023:4146 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Via RHSA-2023:4262 https://access.redhat.com/errata/RHSA-2023:4262 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Red Hat Enterprise Linux 8.4 Telecommunications Update Service Via RHSA-2023:4255 https://access.redhat.com/errata/RHSA-2023:4255 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Red Hat Enterprise Linux 8.4 Telecommunications Update Service Via RHSA-2023:4256 https://access.redhat.com/errata/RHSA-2023:4256 This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Advanced Update Support Via RHSA-2023:4699 https://access.redhat.com/errata/RHSA-2023:4699 This issue has been addressed in the following products: Red Hat Enterprise Linux 7.6 Advanced Update Support Via RHSA-2023:4696 https://access.redhat.com/errata/RHSA-2023:4696 This issue has been addressed in the following products: Red Hat Enterprise Linux 7.7 Advanced Update Support Via RHSA-2023:5419 https://access.redhat.com/errata/RHSA-2023:5419 This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2023:5574 https://access.redhat.com/errata/RHSA-2023:5574 This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2023:5621 https://access.redhat.com/errata/RHSA-2023:5621 This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2023:5622 https://access.redhat.com/errata/RHSA-2023:5622 |