Muximux icon indicating copy to clipboard operation
Muximux copied to clipboard

White page - Error 500

Open rlambert27 opened this issue 6 years ago • 31 comments

Hello,

I installed Muximux quite easily yesterday, all of a sudden though I started getting a white page and a 500 error. Although all my sub-domains work. I checked the nginx error log and found

2017/07/13 22:50:47 [error] 7599#7599: *15 FastCGI sent in stderr: "PHP message: PHP Warning:  syntax error, unexpected '=' in settings.ini.php on line 3
 in /var/www/muximux/vendor/pear-pear.php.net/Config_Lite/Config/Lite.php on line 134
PHP message: PHP Fatal error:  Uncaught Config_Lite_Exception_Runtime: failure, can not parse the file: settings.ini.php in /var/www/muximux/vendor/pear-pear.php.net/Config_Lite/Config/Lite.php:136
Stack trace:
#0 /var/www/muximux/vendor/pear-pear.php.net/Config_Lite/Config/Lite.php(894): Config_Lite->read('settings.ini.ph...', 0)
#1 /var/www/muximux/muximux.php(63): Config_Lite->__construct('settings.ini.ph...')
#2 /var/www/muximux/muximux.php(29): write_ini()
#3 /var/www/muximux/index.php(3): require('/var/www/muximu...')
#4 {main}
  thrown in /var/www/muximux/vendor/pear-pear.php.net/Config_Lite/Config/Lite.php on line 136" while reading response header from upstream, client: 184.91.134.60, server: rlplex.ca, request: "POST$

Any ideas? I tried:

  1. Erasing the complete Muximux install
  2. Cloning again
  3. It works fine, right up until I edit the settings and save. Then when I reload, boom, white page with 500 error again.

rlambert27 avatar Jul 14 '17 02:07 rlambert27

In case it helps, my reverse nginx file contains:

server {
    listen 80;
    server_name rlplex.ca 192.168.86.75;
    root /var/www/muximux;
    index index.php;

    location / {
      try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
      try_files $uri =404;
      include fastcgi_params;
      fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

rlambert27 avatar Jul 14 '17 02:07 rlambert27

What version of PHP are you running and what addons are there? (php gd, zlib and so on).

mescon avatar Jul 14 '17 09:07 mescon

I followed this guide : NGINX first : https://www.htpcguides.com/configure-plex-media-server-reverse-proxy-nginx-linux/ Muximux after : https://thisisforsomething.com/guide/guide-to-plex-media-server-on-ubuntu-server-16-04/

Other than that I have not installed anything else out of the box unless it was in PlexMediaServer, Deluge, CouchPotato, PlexRequests.Net, SickRage or PlexPY.

What's weird is that it worked fine for a full day, then suddenly it stopped. I didn't do any updates.

rlambert27 avatar Jul 14 '17 12:07 rlambert27

Hm... syntax error, unexpected '=' in your error makes me think that maybe there is some = in there that isn't being parsed the way it should be. Open up settings.ini.php and have a look at it and see if it's in there somewhere. Maybe the password encryption function is messing something up, so try an easy password such as test instead. You can just delete the username/password parts of settings.ini.php and it will be reset.

mescon avatar Jul 14 '17 20:07 mescon

Hmmmm, my settings.ini.php file contained:

; <?php die('Access denied'); ?>
[QPAMxojMMGR6Gp_0C_Suif6hhPu3TNyGU4Kd0DD1NOqy6cx3PE9EC6ShxyQiaGHYyRRZoyu_ygQhBu$
 = "="

Obviously that is not correct. I deleted all the files and re-installed and now seems to work fine. Not sure that I did anything different from last time but it's working now.

I'll update in a day or two once i've confirmed that it's working for more than 24 hours since it worked fine last time for 24 hours and then it stopped working.

rlambert27 avatar Jul 18 '17 03:07 rlambert27

Happened again! I didn't change anything and suddenly stopped working, i'll check out the logs tonight and see what happened to my settings.ini.php file.

rlambert27 avatar Jul 19 '17 17:07 rlambert27

Same things in my settings.ini.php file:

; <?php die('Access denied'); ?>
[RaBXkImeZQ4kr6S9kdO8Vpdi8EN1DKdxvJY1bIVLDsGUmSJoLKWMDgGU4bv4rcJtLOWXxh_Ula8ltI$
 = ""

I checked owner and it's

-rw-r--r-- 1 www-data www-data 406 Jul 19 11:49 settings.ini.php

I wonder how i could audit the file to be see who is changing it!!!

rlambert27 avatar Jul 20 '17 00:07 rlambert27

I thought i'd be smart and do a chattr +i on the file but now Muximux won't load. Any thoughts?

rlambert27 avatar Jul 20 '17 12:07 rlambert27

I just started to get this same error out of no were for some reason.

Im using the docker version with unraid https://hub.docker.com/r/linuxserver/muximux/

kube1984 avatar Jul 22 '17 12:07 kube1984

I've been having the exact same problem every few weeks, First issue I found about it. I'm setting my setting.ini.php to mod 400 to see if it helps.

EDIT: Muximux does not like that. Set it to 600.

RafaelSchridi avatar Aug 11 '17 03:08 RafaelSchridi

I also experience the very same issue on Debian Jessie 8.9 x64 with Apache 2.4.10 and PHP 5.6.30. I've made a backup of my settings.php.ini file, so that I don't have to reconfigure everything when this happens, I recommend others to do this as well.

savage93 avatar Aug 11 '17 09:08 savage93

I had to switch away, it was happening too frequently for me to have to overwrite my settings file each time. Maybe if the root issue is found i'll come back :-(

rlambert27 avatar Aug 11 '17 13:08 rlambert27

I've got some interesting news regarding this issue. It appears to me that this problem happens because of someone using an unknown exploit on the login page, because every time I replace the settings with the backed up version, it works for half a minute or so, and after that this issue happens, and I always see the same IP accessing my site logged in my apache2 logs in this period. I also tried to block this IP, and after that the issue magically stopped. Currently I'm trying to figure out what the POST content could be that causes the problem to happen, using mod_security, but the content logged looks gibberish to me: log

savage93 avatar Aug 13 '17 12:08 savage93

I think I've found the "exploit" too: the POST parameters aren't verified on the server-side correctly, e.g. I could achieve a similar result by simply modifying the input fields' names to something else like "sha" and then input some random text, click on submit, and the settings file got rewritten again: image.

savage93 avatar Aug 13 '17 15:08 savage93

@savage93 - Well, this isn't cool at all. Maybe it's time I get off my a$$ and take a look at improving things a bit with some of the tricks I've learned since I've been working on other things.

Updates should be forthcoming...

d8ahazard avatar Aug 14 '17 13:08 d8ahazard

Good to see you again @d8ahazard :-)

mescon avatar Aug 14 '17 15:08 mescon

@savage93 - Why don't you check out the commit I've pushed to the develop branch. This should properly wrap all post data with a secret, so that random data can't just be blasted at the server.

This is a temporary fix, note that I'll be doing away with the necessity for the "save" button entirely in the final update I'm cooking - once you change a value in the UI, it will automagically get saved to config. :D

d8ahazard avatar Aug 17 '17 21:08 d8ahazard

@d8ahazard - Your solution definitely won't let random malicious POST requests messing up the settings, however, while highly unlikely, someone who knows the source of Muximux could still could cause trouble by sending the correct requests needed (see issue #158, the secret.txt can be read by anyone without any authentication!). I think my quick and dirty modification would be somewhat safer by using the SESSION variable created by the login script, since that can't just be set from the client-side.

The settings code change you mentioned should definitely fix all these issues - while also making the UX a lot better - so I'm really looking forward to it. :)

savage93 avatar Aug 18 '17 07:08 savage93

See my comment on issue #158 - you'd be absolutely correct, except of course, if I'd have moved storage of the secret to settings.ini.php...which I did. There, it should be protected like the rest of settings,and validated on each post/request. ;)

On Fri, Aug 18, 2017 at 2:37 AM, savage93 [email protected] wrote:

@d8ahazard https://github.com/d8ahazard - Your solution definitely won't let random malicious POST requests messing up the settings, however, while highly unlikely, someone who knows the source of Muximux could still could cause trouble by sending the correct requests needed (see issue #158 https://github.com/mescon/Muximux/issues/158, the secret.txt can be read by anyone without any authentication!). I think my quick and dirty modification would be somewhat safer by using the SESSION variable created by the login script, since that can't just be set from the client-side.

The settings code change you mentioned should definitely fix all these issues - while also making the UX a lot better - so I'm really looking forward to it. :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mescon/Muximux/issues/157#issuecomment-323282871, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjuNCo9e8PekZ-WA5L3IsLfkB-nGfKGks5sZT9HgaJpZM4OXxPQ .

d8ahazard avatar Aug 18 '17 12:08 d8ahazard

Oh, my bad then, I've missed that comment. :)

savage93 avatar Aug 18 '17 12:08 savage93

Fixed in the developer branch, will close when rewrite code is merged. Labeling for my own reference.

d8ahazard avatar Aug 23 '17 01:08 d8ahazard

ive been having this issue for a while and i just seen this thread i posted orginaly here #162 i have just reinstalled muximux is the issue fixed now or am i going to have to reinstall everyday

FuckThisAlias avatar Sep 13 '17 19:09 FuckThisAlias

You can wait for the changes to be pushed to master or use the dev branch for a bit.

RafaelSchridi avatar Sep 13 '17 20:09 RafaelSchridi

Are there any other issues i should be aware of in the dev branch

FuckThisAlias avatar Sep 13 '17 20:09 FuckThisAlias

Not that I know of

RafaelSchridi avatar Sep 13 '17 21:09 RafaelSchridi

@d8ahazard is working on fixing a bunch of these bugs as well as re-writing heaps of the codebase... the experimental branch is where he's working, and currently I am not able to use that one. This will be fixed sooner or later, as soon as @d8ahazard has had some time for himself :-)

mescon avatar Sep 13 '17 22:09 mescon

Hey, sorry all, work has been hectic the past few weeks, affording me little time for any other projects. Hopefully, next week will be a bit calmer for me. :D

On Wed, Sep 13, 2017 at 5:00 PM, mescon [email protected] wrote:

@d8ahazard https://github.com/d8ahazard is working on fixing a bunch of these bugs as well as re-writing heaps of the codebase... the experimental branch is where he's working, and currently I am not able to use that one. This will be fixed sooner or later, as soon as @d8ahazard https://github.com/d8ahazard has had some time for himself :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mescon/Muximux/issues/157#issuecomment-329309412, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjuNOsI2nTadVyA1ImOxyJJBeUw5cTOks5siFB_gaJpZM4OXxPQ .

d8ahazard avatar Sep 15 '17 04:09 d8ahazard

Still appears to still be an issue. I had a fresh install using docker go bad after a day or so

RyanEwen avatar Jul 13 '18 14:07 RyanEwen

I still have the same issue here, got a 500 every 3-4day

Suertzz avatar Jun 21 '19 00:06 Suertzz

This is still happening. Got the following in my settings.ini.php today

; <?php die('Access denied'); ?>
[<methodCall>_<methodName>system_listMethods</methodName>_<params></params>_</methodCall>]
 = ""

mstormo avatar Mar 22 '20 22:03 mstormo