Urgent security issue in NGINX/php-fpm

Originally published at: https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/

Dear system administrators,

In the last 24 hours, a new security risk has emerged around NGINX, documented in CVE-2019-11043. This exploit allows for remote code execution on some NGINX and php-fpm configurations. If you do not run NGINX, this exploit does not effect you.

Unfortunately the default Nextcloud NGINX configuration is also vulnerable to this attack. We recommend all system administrators take immediate actions:

  1. Upgrade your php packages to the latest version. A new release that fixes the issue is to be released on the 24th of October. See https://www.php.net/archive/2019.php#2019-10-24-1 Upstream php packages with the fix are:

    1. 7.1.33

    2. 7.2.24

    3. 7.3.11

  2. Update your nginx config file. We have updated the configuration in our documentation.

Since there are only two changes in the nginx configuration we highlight them here:

    location / {
                rewrite ^ /index.php$request_uri;
            }
        

Should become

    location / {
                rewrite ^ /index.php;
            }
        

Note the removal of $request_uri

And

     location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
                fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $path_info;
                fastcgi_param HTTPS on;
                # Avoid sending the security headers twice
                fastcgi_param modHeadersAvailable true;
                # Enable pretty urls
                fastcgi_param front_controller_active true;
                fastcgi_pass php-handler;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
            }
        

Should become:

    location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
                fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
                try_files $fastcgi_script_name =404;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $path_info;
                fastcgi_param HTTPS on;
                # Avoid sending the security headers twice
                fastcgi_param modHeadersAvailable true;
                # Enable pretty urls
                fastcgi_param front_controller_active true;
                fastcgi_pass php-handler;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
            }
        

Note the addition of the $try_files $fastcgi_script_name =404;

Then restart your webserver and the issue is mitigated. See our full documentation here.

If you are running the docker containers from https://hub.docker.com/_/nextcloud those will also receive updates with new php-fpm versions when available.

If you are a Nextcloud customer, you should already have been notified of this issue. If you need any assistance, contact our support team through our portal.

4 Likes

My Ubuntu 18.04 doesn’t propose me PHP 7.3.11.
I am on 7.3.10, how can i force the repo to update ?

Hi @Nemskiller

You can follow the steps from this answer:

Just replace every 7.2 with 7.3 in his answer.

He stated that as an update in his answer as well:

Update:

Yesterday, I’ve used the above set of commands to install PHP 7.3 on Ubuntu 16.04 and everything went completely fine. Just replace 7.2 with 7.3 within these commands - the entire process took about 7 minutes.

7.3.11 packages are not yet released on https://launchpad.net/%7Eondrej/+archive/ubuntu/php/+index?batch=75&memo=150&start=150 .

I am sure it will come soon.

1 Like

@system And the workaround is sufficient and reliable?

The last comment from the bug report reads:

A method to quick fix this problem.
If you want to use PATH_INFO in php, and do not want to patch and recompile PHP.

Add this line before ALL YOUR “location ~ .php(/|$) {” LINES in nginx confs:

rewrite ^(.*?)\n $1;  #Fix CVE-2019-11043 (THIS LINE!!!)
location ~ \.php(/|$) {
  ...
  fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
  ...

That will truncate PATH_INFO after “\n” while URL contains “%0a”.

(https://bugs.php.net/bug.php?id=78599)

Is this something which should be added as well?

@system I noticed that try_files was included, while further down the config we still set PATHINFO. Doesn’t that cause issues? Due to a bug try_files resets $fastcgi_path_info…
http://trac.nginx.org/nginx/ticket/321

1 Like

On Arch, those directives are

SCRIPT_FILENAME and PATH_INFO (notice the _ between the words). Got bit once again and spent some time thinking my server was borked. Hope it helps someone else.

3 Likes

To whom it may concern.

I appreciate such urgent info and the resp. Nextcloud announcement. However, for the convenience of administrators and other interested parties one may add several links such as:

Beispielhaft sei noch der Artikel Debian und CVE-Kompatibilität für deutschsprachige Personen erwähnt. - English: Debian and CVE compatibility

:innocent:

1 Like
php7.3-fpm:
  Installed: 7.3.11-1+ubuntu18.04.1+deb.sury.org+1
  Candidate: 7.3.11-1+ubuntu18.04.1+deb.sury.org+1
  Version table:
 *** 7.3.11-1+ubuntu18.04.1+deb.sury.org+1 500
        500 http://ppa.launchpad.net/ondrej/php/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
1 Like

I got hit by this also, I’m not sure whether SCRIPTFILENAME and PATHINFO are valid anywhere?

I think it might just be a mistake in the blog post?

e.g. https://docs.nextcloud.com/server/17/admin_manual/installation/nginx.html?highlight=nginx has underscores.

1 Like

I think this kind of news should be sticky at least few days. Can you do it? @system

What about Nextcloud installed via Ubuntu snaps?
Did it got all required updates to its nginx automatically?

4 Likes

Here’s more updates since this news thread was opened.

1 Like

I run a fully-refreshed snap on Ubuntu 16.04. Version information is installed: 16.0.5snap2 (16402) 228MB and I do not see nginx running at all. That leads me to believe the version of php-fpm (which is installed) is not a problem.

Services from nextcloud snap:

$ sudo snap services nextcloud
Service                    Startup  Current   Notes
nextcloud.apache           enabled  active    -
nextcloud.mdns-publisher   enabled  active    -
nextcloud.mysql            enabled  active    -
nextcloud.nextcloud-cron   enabled  active    -
nextcloud.nextcloud-fixer  enabled  inactive  -
nextcloud.php-fpm          enabled  active    -
nextcloud.redis-server     enabled  active    -
nextcloud.renew-certs      enabled  active    -
1 Like

Nextcloud-Snap comes with Apache and not with nginx, so you should be safe:

1 Like

I’m just wondering (but could be an idiotic thought): are users really safe just because they run apache? I mean, the bug was actually in PHP (not nginx) in combination with php-fpm. Doesn’t apache use php-fpm as well?

As said, just wondering. Could be a totally mislead thought.

1 Like

WARNING to everybody with nginx version: nginx/1.10.3 (Debian stretch latest)

The directive or cgi_parameter SCRIPTFILENAME will render your nextcloud website blank.
change it to SCRIPT_FILENAME

5 Likes

Are both “Immediate actions” required to be secure? My upstream distribution does not have updated packages available currently.

I am relying on this statement from the initial post:

1 Like

Is Nginx (under Plesk) with the directives set from this guide affected?