Red Hat Bugzilla – Bug 1533836
CVE-2018-1000001 glibc: realpath() buffer underflow when getcwd() returns relative path allows privilege escalation
Last modified: 2018-10-31 17:38:10 EDT
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