Bug 27389 - NSS chroot hardening causes regressions in chroot deployments
Summary: NSS chroot hardening causes regressions in chroot deployments
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: network (show other bugs)
Version: 2.33
: P2 normal
Target Milestone: 2.34
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-10 08:19 UTC by sjon
Modified: 2021-03-11 08:13 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sjon 2021-02-10 08:19:18 UTC
I have an issue that I suspect is caused by a recent glibc change, but I haven't 100% ruled out another cause, so this report might be bogus.

I use PHP-FPM [1] with chroots enabled. Since upgrading glibc, name resolving (via DNS) fails with "getaddrinfo failed: System error" in my chroot and I'm pretty sure it is caused by the recently added "Block attempts to dlopen any module we haven't already opened" [2]

What seems to happen is that the PHP-FPM master process only loads libnss_files.so.2 and libnss_systemd.so.2 because it uses that to resolve the username (it matches nsswitch which contains: "passwd: files systemd")

If any of the FPM workers then attempts to perform dns resolving, that fails because libnss_dns.so.2 has not been loaded yet (even though I made it available in the chroot), and due to the recent change, it won't be loaded either.

I have confirmed I can "fix" it by forcing the fpm master to load the dns module by modifying nsswitch.conf outside of the chroot to contains "passwd: dns files systemd", this fixes it

1. https://www.php.net/manual/en/install.fpm.php
2. https://github.com/bminor/glibc/commit/429029a73ec2dba7f808f69ec8b9e3d84e13e804#diff-9305f1992144bc8c923a840d44827642f1c3f57e3df85a69357fff2fe7370fb8R352
Comment 1 sjon 2021-02-10 08:41:14 UTC
Some more information for clarification:

# grep dns /etc/nsswitch
hosts: files dns

# strace -eopenat -f /usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf 2>&1|grep nss
openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 22

# curl https://localhost/test.php
getaddrinfo failed: System error

--

# grep dns /etc/nsswitch
passwd: dns files systemd
hosts: files dns

# strace -eopenat -f /usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf 2>&1|grep nss
openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 22

# curl https://localhost/test.php
works
Comment 2 Florian Weimer 2021-02-16 12:45:06 UTC
I've started a discussion on libc-alpha:

NSS chroot protection
https://sourceware.org/pipermail/libc-alpha/2021-February/122714.html
Comment 3 Howard Chu 2021-02-16 14:47:04 UTC
(In reply to Florian Weimer from comment #2)
> I've started a discussion on libc-alpha:
> 
> NSS chroot protection
> https://sourceware.org/pipermail/libc-alpha/2021-February/122714.html

Can you link to more context on what security regressions this change was meant to address? chrooted servers have been running for decades using the NSS databases of the chroot jail, and this change breaks all of them.
Comment 4 Florian Weimer 2021-02-16 14:50:52 UTC
It's CVE-2019-14271:

https://nvd.nist.gov/vuln/detail/CVE-2019-14271

(The Docker fix is likely incomplete depending on nsswitch.conf contents.)

That issue is of no concern once the service is running, it applies to the construction of the chroot contents from the outside.
Comment 5 Florian Weimer 2021-03-04 11:46:50 UTC
Fixed for 2.34.  Also backported to 2.33.

commit 58673149f37389495c098421085ffdb468b3f7ad
Author: DJ Delorie <dj@redhat.com>
Date:   Thu Feb 18 15:26:30 2021 -0500

    nss: Re-enable NSS module loading after chroot [BZ #27389]

    The glibc 2.33 release enabled /etc/nsswitch.conf reloading,
    and to prevent potential security issues like CVE-2019-14271
    the re-loading of nsswitch.conf and all mdoules was disabled
    when the root filesystem changes (see bug 27077).

    Unfortunately php-lpfm and openldap both require the ability
    to continue to load NSS modules after chroot. The packages
    do not exec after the chroot, and so do not cause the
    protections to be reset. The only solution is to re-enable
    only NSS module loading (not nsswitch.conf reloading) and so
    get back the previous glibc behaviour.

    In the future we may introduce a way to harden applications
    so they do not reload NSS modules once the root filesystem
    changes, or that only files/dns are available pre-loaded
    (or builtin).

    Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Comment 6 Eugene Crosser 2021-03-11 08:13:57 UTC
Just as a note, the change has also broken postfix. Its smtp client enters chroot after start, and then down the road calls `getservbyname()` which fails.