We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    Will having register_globals off neutralize this threat or should we be renaming all the snippet files in our packages?

      Did I help you? Buy me a beer
      Get my Book: MODX:The Official Guide
      MODX info for everyone: http://bobsguides.com/modx.html
      My MODX Extras
      Bob's Guides is now hosted at A2 MODX Hosting
      • 16034
      • 107 Posts
      register_globals=off neutralizes this threat.
        MODx snippet-glossary 101:
        Ditto = Content Lister -- Wayfinder == Menu Builder -- Jot = Comment Control
        • 33372
        • 1,611 Posts
        Quote from: Kleist at Nov 25, 2008, 04:56 PM

        register_globals=off neutralizes this threat.
        ...as well as all similar XSS attacks that pass values via the query string, session, or post vars.
          "Things are not what they appear to be; nor are they otherwise." - Buddha

          "Well, gee, Buddha - that wasn't very helpful..." - ZAP

          Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
          • 30765
          • 66 Posts
          Just turning off register_globals won’t protect against other poorly-written third-party PHP scripts. I can’t see any reason why Apache should be executing PHP in the assets folder at all. So I’ve placed a .htaccess file inside the assets folder to disable access to *.php files.

          <Files ~ "\.php">
          	Order allow,deny
          	Deny from all
          </Files>


          I haven’t noticed any problems (yet!). (The assets folder is a special case, so it’s worth speeding things up a bit by encouraging caching and compressing where possible -- I have these instructions in that .htaccess file too, FWIW.)

          #Avoid (expensive) MODx 404s
          RewriteEngine Off
          
          # From http://www.askapache.com/htaccess/apache-speed-compression.html
          <FilesMatch "\.(js|css)$">
          SetOutputFilter DEFLATE
          </FilesMatch>
          
          # From http://developer.yahoo.com/performance/rules.html#etags
          FileETag none


          It might help someone ...

          Cheers
          Matt
            • 33372
            • 1,611 Posts
            Actually, there are a ton of PHP files in the assets subfolder that need to be executed by snippets, plugins, etc. (the assets folder structure is an unfortunate legacy from previous incarnations of the software). Most of them are just included by other scripts (so your deny rule shouldn’t affect those), but I believe many are called from pop-ups and iframes in the Manager (e.g., TinyMCE, etc.) and therefore would be blocked by your rule. So I would test this thoroughly before you turn over a site with it to clients or anyone else who wouldn’t understand what was going on and know how to debug it.
              "Things are not what they appear to be; nor are they otherwise." - Buddha

              "Well, gee, Buddha - that wasn&#39;t very helpful..." - ZAP

              Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
              • 30765
              • 66 Posts
              Quote from: ZAP at Nov 25, 2008, 09:20 PM

              So I would test this thoroughly before you turn over a site with it to clients or anyone else who wouldn’t understand what was going on and know how to debug it.

              Good advice. Still, it is working fine from what I can see; the manager seems to work, including TinyMCE (which is JavaScript, rather than PHP, no? -- although its language files are PHP.) Even QuickEdit is working which I thought might break.

              Clients aren’t an issue for us, though -- the sites are our own -- but just to be sure, I searched for PHP files in the assets folder and couldn’t see an obvious problem. If/when we find a problem we can always re-enable PHP for that directory or file.

              Your broader point, though -- don’t do this casually -- is quite right and I should have said so. Presumption is the mother of all ..., etc.

              Cheers
              Matt
                • 13481
                • 97 Posts
                Not sure if this has been mentioned yet but this vulnerability is in all 0.9.6 versions since that’s when reflect started to be included in the source by default.

                James
                  • 1058
                  • 14 Posts
                  Hi all around here, this is a global problem in php - not only MODx.

                  If one will get access or do crazythings with/on your your webserver, then he always will penetrate a system with this lame lame php-shell.. this c99.txt exploit is some years old I think.
                  So if you have some very common settings in php.ini set, it’s like an wide opened door to a house with php, but php can be secure - even without things like safe_mode which may brings other problems.

                  So if you set some var’s in php.ini or via .htaccess then you can be aware of some stuff - here an example:
                  register_globals = off
                  allow_url_fopen = off
                  safe_mode = on
                  open_basedir = <path to web-root>
                  disable_functions = exec,system,passthru,shell_exec,popen,escapeshellcmd,proc_open,proc_nice,ini_restore
                  display_errors = off
                  


                  Specialy this exploit makes use of some dangerous functions to do it’s work, as one might see’s in code from the exploit. It’s perhaps basicly better to secure your webserver, then only fix the problems in MODx.
                    • 13481
                    • 97 Posts
                    I just want to point out that, unlike .htaccess files, a custom php.ini might only work in the directory that it is in. I’m not sure if it is always this way, but I do know that’s how it works on the servers I’m on. So don’t set a custom php.ini in your web root with register_globals=off and assume that you are safe site-wide, make sure you test it out - I’m definitely glad I did.

                    James
                      • 33372
                      • 1,611 Posts
                      Quote from: devtrench at Nov 26, 2008, 07:54 PM

                      I just want to point out that, unlike .htaccess files, a custom php.ini might only work in the directory that it is in.
                      This is a very good point, since a lot of servers behave this way.
                        "Things are not what they appear to be; nor are they otherwise." - Buddha

                        "Well, gee, Buddha - that wasn&#39;t very helpful..." - ZAP

                        Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options