[Security] Php and Nginx security issue

Hello, I learn on this blog post from Nextcloud https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/ that there is a security issue with Php and Nginx.

It seems that the fix has not been backported to 7.0 I think it will be available soon in debian 9 repos. But I do not know if there is anything else than update to do… ?

2 Likes

+1
The fix seems rather trivial to manually apply, but is it needed or will it come with an update soon ?

+1 Other projects recommend to block all web access until the bug is updated.

Updated info for debian fix will be available here : https://security-tracker.debian.org/tracker/CVE-2019-11043

For people who wants to protect their server from this attack, i suggest this:

sed -i '/try_files $fastcgi_script_name =404;/d' /etc/nginx/conf.d/*/*.conf
sed -i '/fastcgi_split_path_info/a try_files $fastcgi_script_name =404;' /etc/nginx/conf.d/*/*.conf
service nginx reload

EDIT: it might break some apps (about libreto app it’s sure)

2 Likes

I see an update on the Yunohost update tool about Nextcloud
15.0.11 to 15.0.12
Is this update is fixing this issue ?

Yes it does : https://github.com/YunoHost-Apps/nextcloud_ynh/pull/233/files

It fixed this issue on Nextcloud. The problem is on several php apps packages in YunoHost…

1 Like

Quels packages parmis les packages officiels à part Nextcloud?

Par officiel tu veux dire niveau 7 ? Je ne sais pas. A peu prés toutes les apps PHP. Mais tu peux savoir quelles sont les apps impactées en lançant:

grep -r "fastcgi_split_path_info" /etc/nginx

Il y a notamment redirect_ynh et la custom webapp qui sont pas mal utilisées

1 Like

J’ai testé grep -r “fastcgi_split_path_info” /etc/nginx
Terrrrrrrrrrrrrible…toutes les applis sont concernées! :grinning:
Il y a t il une solution définitive en vue n’empêchant pas le fonctionnement des applications?

1 Like

Idem :joy:

Concrètement, tant qu’il n’y a pas de mises à jour spécifiques de php, existe-t-il un moyen de limiter les risques ?

For people who wants to protect their server from this attack, i suggest this…

Thanks. I’m guessing if we make these manual changes though they might get in the way of package/app-level changes which will (hopefully?) come through?

As said above if you apply these lines you should be safe (in theory)

sed -i '/try_files $fastcgi_script_name =404;/d' /etc/nginx/conf.d/*/*.conf
sed -i '/fastcgi_split_path_info/a try_files $fastcgi_script_name =404;' /etc/nginx/conf.d/*/*.conf
service nginx reload

This solution is logically quite correct, even if for libreto I found that it broke the app. (A specific capital letter for libreto exists.

Note: this solution will manually modify your app configurations, in theory they will be rewritten the next time the app is updated.

Last night I worked on a generic fix via ssowat, but it takes me a little time to do a test with the exploit that has been published, help is welcome.


@thierry56 @Sango
Comme dit plus haut si vous appliquez ces lignes vous devriez être en sûreté (en théorie)

sed -i '/try_files $fastcgi_script_name =404;/d' /etc/nginx/conf.d/*/*.conf
sed -i '/fastcgi_split_path_info/a try_files $fastcgi_script_name =404;' /etc/nginx/conf.d/*/*.conf
service nginx reload

Cette solution est logiquement plutôt correcte, même si pour libreto j’ai constaté que ça cassait l’app. (Une maj spécifique pour libreto existe.

Note: cette solution va modifier manuellement vos configurations de vos apps, en théorie elle seront réécrites à la prochaines mises à jour de l’app donc.

Hier soir j’ai travaillé sur un fix générique via ssowat, mais il me faut un peu de temps pour faire un test avec l’exploit qui a été publié, toute aide est la bienvenue.

2 Likes

I just tried to run the PoC on my install, it doesn’t seem to trigger the vulnerability…


Sorry, I was misguided, in our case we get redirected to /yunohost/sso/. Adding the try_files to the config generates a 404. In the Nextcloud post they also mention removing $request_uri from location /, and this removes the 404 and you get redirected to /index.php/apps/files.

If i read the bug report right, is is solved…
“php7.0 source stretch 7.0.33-0+deb9u6”
(https://security-tracker.debian.org/tracker/source-package/php7.0)