Bug 1533836 (CVE-2018-1000001) - CVE-2018-1000001 glibc: realpath() buffer underflow when getcwd() returns relative path allows privilege escalation
Summary: CVE-2018-1000001 glibc: realpath() buffer underflow when getcwd() returns rel...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-1000001
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=important,public=20180111,repo...
Depends On: 1533837 1533838 1533839 1533840 1534634 1534635 1669038
Blocks: 1530306
TreeView+ depends on / blocked
 
Reported: 2018-01-12 10:48 UTC by Adam Mariš
Modified: 2019-08-05 15:29 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-08 23:35:46 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0805 None None None 2018-04-10 08:22:18 UTC
Sourceware 22679 None None None 2019-07-26 08:01:14 UTC

Description Adam Mariš 2018-01-12 10:48:43 UTC
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

Comment 1 Adam Mariš 2018-01-12 10:48:45 UTC
Acknowledgments:

Name: halfdog

Comment 2 Adam Mariš 2018-01-12 10:49:23 UTC
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]

Comment 7 Florian Weimer 2018-02-05 12:22:46 UTC
There is a report of a regression related to the getcwd fix:

https://lists.gluster.org/pipermail/gluster-users/2018-January/033293.html

Comment 8 Florian Weimer 2018-02-05 19:19:39 UTC
(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.

Comment 12 Raphael Sanchez Prudencio 2018-03-22 17:35:58 UTC
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.

Comment 13 Dave Dykstra 2018-03-28 21:24:21 UTC
(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?

Comment 14 Dave Dykstra 2018-04-04 18:28:05 UTC
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.

Comment 15 Raphael Sanchez Prudencio 2018-04-05 08:08:39 UTC
(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.

Comment 16 Dave Dykstra 2018-04-05 12:03:52 UTC
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?

Comment 17 Dave Dykstra 2018-04-05 20:33:44 UTC
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?

Comment 18 Raphael Sanchez Prudencio 2018-04-06 11:22:15 UTC
(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.

Comment 21 errata-xmlrpc 2018-04-10 08:22:07 UTC
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

Comment 23 Doran Moppert 2019-02-15 01:31:56 UTC
Statement:

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.


Note You need to log in before you can comment on or make changes to this bug.