Bug 1533836 - (CVE-2018-1000001) CVE-2018-1000001 glibc: realpath() buffer underflow when getcwd() returns relative path allows privilege escalation
CVE-2018-1000001 glibc: realpath() buffer underflow when getcwd() returns rel...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20180111,repo...
: Security
Depends On: 1533837 1533838 1533839 1533840 1534634 1534635
Blocks: 1530306
  Show dependency treegraph
 
Reported: 2018-01-12 05:48 EST by Adam Mariš
Modified: 2018-05-31 17:36 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 22679 None None None 2018-02-05 07:28 EST
Red Hat Product Errata RHSA-2018:0805 None None None 2018-04-10 04:22 EDT

  None (edit)
Description Adam Mariš 2018-01-12 05:48:43 EST
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 05:48:45 EST
Acknowledgments:

Name: halfdog
Comment 2 Adam Mariš 2018-01-12 05:49:23 EST
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 07:22:46 EST
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 14:19:39 EST
(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 13:35:58 EDT
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 17:24:21 EDT
(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 14:28:05 EDT
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 04:08:39 EDT
(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 08:03:52 EDT
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 16:33:44 EDT
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 07:22:15 EDT
(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 04:22:07 EDT
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

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