Bugzilla – Bug 1218475
VUL-0: CVE-2024-22365: pam: pam_namespace misses O_DIRECTORY flag in `protect_dir()`
Last modified: 2024-07-09 20:30:17 UTC
There is a potential local DoS issue in the pam_namespace module. This is a result from my review in bug 1218108. A small issue that is still under embargo and will likely be posted to the distros mailing lists in a while. This is the issue description, part of a longer report I shared with the PAM upstream maintainers by mail: 3) `O_DIRECTORY` Flag is Missing in `protect_dir()` =================================================== In `protect_dir()` the target path for the polydir mount, which can be under control of an unprivileged user, is followed, starting from the file system root. Each path component that is under non-root control is protected from user manipulation, by bind mounting the path upon itself. While this approach feels unusual, it should be effective to prevent any shenanigans on the side of the unprivileged user for whom the directory is mounted. There is one bit missing though: The algorithm is not passing the `O_DIRECTORY` flag to `openat()` and is thus subject to special files like FIFOs being placed in user controlled directories. This can easily be reproduced e.g. using this configuration entry: $HOME/tmp /var/tmp/tmp-inst/ user:create root An unprivileged user (that is not yet in a corresponding mount namespace with ~/tmp mounted as a polydir) can now place a FIFO there: nobody$ mkfifo $HOME/tmp A subsequent attempt to login as this user with `pam_namespace` configured will cause the `openat()` in `protect_dir()` to block. The attached patch #0002 simply adds `O_DIRECTORY` to the open flags and thus fixes this attack vector. Even with this patch applied the unprivileged user can still prevent the polyinstantiated directory from being mounted by placing a FIFO there. I don't believe that `pam_namespace` gives (or should give) any guarantees in this regard, so I don't consider it a problem. -- I will attach the patch to this bug, but I still need to adjust it a bit after an upstream maintainer gave me feedback about it.
This is an embargoed bug. This means that this information is not public. Please do NOT: - talk to other people about this unless they're involved in fixing the issue - make this bug public - submit this into OBS (e.g. fix Leap/Tumbleweed) until this bug becomes public (e.g. no EMBARGOED tag on the header) Consult with security team if you think that the issue is public and the bug is still private (e.g. subject still contains "EMBARGOED"). Please do NOT make the bug public yourself! Please be aware that the SUSE:SLE-15-SP6:GA and SUSE:ALP:Source:Standard:1.0 codestreams are available via OBS, so do NOT submit there before this is public. These are the steps that are asked from you: 1, Your primary responsibility is to submit a fix for this issue. Here's a how-to for submitting packages for maintenance releases in IBS: https://confluence.suse.com/display/maintenance/How+to+Submit+Packages+or+Containers+to+Maintenance Apart from the GA codestreams mentioned above, you can submit to IBS anytime. This is private and allows us to start testing as soon as possible. 2, We also want to fix openSUSE if it's affected. $ is_maintained $PACKAGE will tell you if the package is inherited from SLES or if it is branched for openSUSE. There are two cases: - It's coming from SLES: The update will automatically be released for openSUSE. Nothing to do for you. - It's branched for openSUSE: You need to submit AFTER the bug became public, to the current openSUSE codestreams. For openSUSE Factory please submit to the devel project of your package AFTER the bug became public. Security will then take the following steps: - We wait for your submission and package them into an incident for QA testing. The QA tester might reach out to you if they find issues with the update. - Once the coordinated release date (CRD), the date this issue should become public, is reached (or for internal findings: once we're done testing), we remove the EMBARGOED tag from this bug and publish the updates. - Only if the bug here is public you may submit to public repositories (OBS). You can contact us at: * IRC: irc.suse.de #security * Do NOT use Slack or any non-SUSE hosted messaging services * Email: security-team@suse.de
I will likely have to request a CVE from Mitre. The upstream maintainer declared no personal interest in a CVE. But since we want to publish this to distros it will make sense to also have a CVE for it.
Created attachment 871615 [details] suggested fix
In attachment 871615 [details] the suggested fix for the issue can be found. The rough roadmap for the publicaton of the security issue is like this: - upstream wants to release a new version in January anyway. - two weeks before that release we will inform the distros mailing list (that is the maximum embargo time for issues posted to the list). - I will request a CVE to track this from Mitre.
Thank you for the analyses and the proposed fix. Thanks to the given instructions, I was able to reproduce the security issue and test with success your proposed patch. The issue purpose here is the call of openat(), for a possible fifo file in no-blocking mode. Matthias, can I have your point of view about adding the flag "O_NONBLOCK" instead of the added "O_DIRECTORY" from your patch, and don't remove the lines after the l:1245 ? It also solves the issue, and a check is done later in the code in the ns_setup() function. Moreover, should we wait for others feedback from PAM upstream maintainers ? Or can we directly submit a fix for SLE12 and SLE15 in IBS ?
(In reply to Valentin Lefebvre from comment #5) > Matthias, can I have your point of view about adding the flag "O_NONBLOCK" > instead of the added "O_DIRECTORY" from your patch, and don't remove the > lines after the l:1245 ? It also solves the issue, and a check is done later > in the code in the ns_setup() function. I guess that would work to, at least to cover the case of a FIFO. But why would you want that? Semantically `O_DIRECTORY` is exactly what is needed here. > Moreover, should we wait for others feedback from PAM upstream maintainers ? > Or can we directly submit a fix for SLE12 and SLE15 in IBS ? I did not receive any negative feedback so far about the patch so I guess you can start submitting in IBS. I don't expect any changes.
(In reply to Matthias Gerstner from comment #6) > I guess that would work to, at least to cover the case of a FIFO. But why > would you want that? Semantically `O_DIRECTORY` is exactly what is needed > here. > I did not receive any negative feedback so far about the patch so I guess > you can start submitting in IBS. I don't expect any changes. Thanks. Maintenance requests has been submitted to SLE12 and SLE15.
(In reply to carlos.lopez@suse.com from comment #9) > Hi, what's the expected CRD for this issue? We don't have one yet. Only that some release is expected in January.
Mitre assigned CVE-2024-22365 for this issue. Upstream communicated to us 2024-01-17 as release date for the fix.
is public
upstream published version 1.6.0 containing the bugfix I published the full report on oss-security: https://www.openwall.com/lists/oss-security/2024/01/18/3
SUSE-SU-2024:0137-1: An update that solves one vulnerability can now be installed. Category: security (moderate) Bug References: 1218475 CVE References: CVE-2024-22365 Sources used: SUSE Linux Enterprise Software Development Kit 12 SP5 (src): pam-1.1.8-24.56.1 SUSE Linux Enterprise High Performance Computing 12 SP5 (src): pam-1.1.8-24.56.1 SUSE Linux Enterprise Server 12 SP5 (src): pam-1.1.8-24.56.1 SUSE Linux Enterprise Server for SAP Applications 12 SP5 (src): pam-1.1.8-24.56.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2024:0136-1: An update that solves one vulnerability and has one security fix can now be installed. Category: security (moderate) Bug References: 1217000, 1218475 CVE References: CVE-2024-22365 Sources used: SUSE Linux Enterprise Micro for Rancher 5.3 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro 5.3 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro 5.4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro 5.5 (src): pam-1.3.0-150000.6.66.1 Basesystem Module 15-SP5 (src): pam-1.3.0-150000.6.66.1 Development Tools Module 15-SP5 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise High Performance Computing 15 SP1 LTSS 15-SP1 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP3 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Real Time 15 SP4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server 15 SP1 LTSS 15-SP1 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server for SAP Applications 15 SP1 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): pam-1.3.0-150000.6.66.1 SUSE Manager Proxy 4.3 (src): pam-1.3.0-150000.6.66.1 SUSE Manager Retail Branch Server 4.3 (src): pam-1.3.0-150000.6.66.1 SUSE Manager Server 4.3 (src): pam-1.3.0-150000.6.66.1 SUSE Enterprise Storage 7.1 (src): pam-1.3.0-150000.6.66.1 SUSE CaaS Platform 4.0 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro 5.1 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro 5.2 (src): pam-1.3.0-150000.6.66.1 SUSE Linux Enterprise Micro for Rancher 5.2 (src): pam-1.3.0-150000.6.66.1 openSUSE Leap Micro 5.3 (src): pam-1.3.0-150000.6.66.1 openSUSE Leap Micro 5.4 (src): pam-1.3.0-150000.6.66.1 openSUSE Leap 15.5 (src): pam-1.3.0-150000.6.66.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
currently ALP seems unfixed
SUSE:ALP:Source:Standard:1.0 pam is 1.5.3m still needs to be fixed
(In reply to Marcus Meissner from comment #20) > SUSE:ALP:Source:Standard:1.0 pam > > is 1.5.3m still needs to be fixed Pam has been update, containing the fix. Should be good, reassigning to Security team.
SUSE-SU-2024:0136-2: An update that solves one vulnerability and has one security fix can now be installed. Category: security (moderate) Bug References: 1217000, 1218475 CVE References: CVE-2024-22365 Maintenance Incident: [SUSE:Maintenance:32004](https://smelt.suse.de/incident/32004/) Sources used: SUSE Linux Enterprise Micro 5.5 (src): pam-1.3.0-150000.6.66.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.