A buffer underflow in realpath() in glibc when getcwd() returns relative path or unreachable path (i.e. not starting with '/') was found that can allow privilege escalation under certain conditions. Reference: http://www.openwall.com/lists/oss-security/2018/01/11/5
Acknowledgments: Name: halfdog
Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1533837] Created glibc-arm-linux-gnu tracking bugs for this issue: Affects: fedora-all [bug 1533840]
There is a report of a regression related to the getcwd fix: https://lists.gluster.org/pipermail/gluster-users/2018-January/033293.html
(In reply to Florian Weimer from comment #7) > There is a report of a regression related to the getcwd fix: > > https://lists.gluster.org/pipermail/gluster-users/2018-January/033293.html See bug 1542180.
This issue is not exploitable in the current versions of Red Hat Enterprise Linux 7 (7.4 and earlier) as they do not support mount namespaces owned by user namespaces. The fix is planned to be included in the future glibc packages updates to avoid introducing this vulnerability in case future Red Hat Enterprise Linux 7 releases add support for mount namespaces owned by user namespaces.
(In reply to Raphael Sanchez Prudencio from comment #12) > This issue is not exploitable in the current versions of Red Hat Enterprise > Linux 7 (7.4 and earlier) as they do not support mount namespaces owned by > user namespaces. The fix is planned to be included in the future glibc > packages updates to avoid introducing this vulnerability in case future Red > Hat Enterprise Linux 7 releases add support for mount namespaces owned by > user namespaces. What about the 7.4 boot option namespace.unpriv_enable described at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.4_release_notes/index#technology_previews_kernel? Doesn't that allow mount namespaces owned by user namespaces?
Raphael: certainly when the 7.4 boot parameter namespace.unpriv_enable=1 and the sysctl user.max_user_namespaces variable is set to a number great than zero, then unprivileged users can do bind mounts into their own namespace. Some of us are depending on this feature to allow users to run isolated containers without having to use a setuid-root application to do it (we are running singularity unprivileged). I would very much like an acknowledgement from Redhat that this is a problem and that the vulnerability in glibc should be patched. Note also that https://access.redhat.com/security/cve/cve-2018-1000001 says that RHEL7 is affected so your March 22 statement is at best inconsistent with other Redhat documentation.
(In reply to Dave Dykstra from comment #14) > Raphael: certainly when the 7.4 boot parameter namespace.unpriv_enable=1 and > the sysctl user.max_user_namespaces variable is set to a number great than > zero, then unprivileged users can do bind mounts into their own namespace. > Some of us are depending on this feature to allow users to run isolated > containers without having to use a setuid-root application to do it (we are > running singularity unprivileged). I would very much like an > acknowledgement from Redhat that this is a problem and that the > vulnerability in glibc should be patched. > > Note also that https://access.redhat.com/security/cve/cve-2018-1000001 says > that RHEL7 is affected so your March 22 statement is at best inconsistent > with other Redhat documentation. Hi Dave, it is affected but it's not exploitable with default kernel parameters, as the exploitability depends on manually enabling kernel parameters we considered Red Hat Enterprise Linux 7 as affected preventively.
Thanks for clarifying. So meanwhile those of us who need this feature on multiuser systems are out of luck. When you say "future glibc updates" does that mean that Redhat is not planning to put out an update specifically to address this problem, meanwhile rendering this technology preview feature unusable for people like us? We have to wait indefinitely until there's some other reason for a glibc update?
According to https://access.redhat.com/solutions/21101, "Asynchronous security errata are still provided for high severity issues with Red Hat's discretion" for technology preview features, and this one is high severity. So does "errata" here mean a patch, or just a notice? If a patch, are you saying that it is Red Hat's discretion in this case that there will be no patch released specifically for it?
(In reply to Dave Dykstra from comment #17) > According to https://access.redhat.com/solutions/21101, "Asynchronous > security errata are still provided for high severity issues with Red Hat's > discretion" for technology preview features, and this one is high severity. > So does "errata" here mean a patch, or just a notice? If a patch, are you > saying that it is Red Hat's discretion in this case that there will be no > patch released specifically for it? Errata means a patch to fix the vulnerability. I suggest opening a Customer Case, it would give more traction to any future fix for this vulnerability.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:0805 https://access.redhat.com/errata/RHSA-2018:0805
Statement: This vulnerability affected the glibc package on Red Hat Enterprise Linux 7.4, however it can only be exploited when mount namespaces owned by user namespaces are enabled, which requires manually configuring a kernel parameter and sysctl that are not enabled by default. Please see the Bugzilla link for more details. This vulnerability affects glibc on Red Hat Enterprise Linux 6. However the kernel included in Red Hat Enterprise Linux 6 does not violate glibc's assumption about the behaviour of getcwd(), so this vulnerability can not be exploited when running with the default kernel. Red Hat Enterprise Linux 6 containers may be vulnerable when running on a host with kernel 2.6.36 or greater.