Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2019-02-14 22:52:18

colin99
Member
Registered: 2005-11-15
Posts: 65

4.71 to 4.72

Oddly the last two updates to Textpattern have been majorly problematic — with lots of fussing to fix things -

Have never had any serious problems before -

After standard (RSYNC) file transfer update, this is the error I get when I go to homepage (running a back-up domain…)

Fatal error: Uncaught Error: Call to undefined function real_max_upload_size() in /home/xxxx/public_html/txp/textpattern/lib/txplib_head.php:127 Stack trace: #0 /home/xxxx/public_html/txp/textpattern/include/txp_auth.php(192): pagetop(‘login’, ‘’) #1 /home/xxxx/public_html/txp/textpattern/include/txp_auth.php(59): doLoginForm(‘’) #2 /home/xxxx/public_html/txp/textpattern/index.php(184): doAuth() #3 {main} thrown in /home/xxxx/public_html/txp/textpattern/lib/txplib_head.php on line 127

Perhaps something is getting fuddled in the RSYNC transfer —

I get this error in my RSYNC attempt -

rsync: rename “/home/xxxx/public_html/txp/textpattern/lib/.txplib_misc.php.fPyYt8” -> “textpattern/lib/txplib_misc.php”: Operation not permitted (1)
rsync error: some files could not be transferred (code 23) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-52.200.1/rsync/main.c(996) [sender=2.6.9]
colin-mac:lib colin$ rsync -r -e “ssh -p xxxx” /Users/xxxx/Desktop/472-needed/ xxxx@xxxxx.com:/home/xxxx/public_html/txp/


On the World Wide Web since Day 1 – Editor/Creator – Coffeecrew.comCoffee.bc.ca
Twitter – Twitter.Com/CoffeeCrew -

Offline

#2 2019-02-15 00:18:16

colin99
Member
Registered: 2005-11-15
Posts: 65

Re: 4.71 to 4.72

Ah yes – this is txplib_misc.php rearing it’s ugly head again with things like eval()
setting off alarms with my ISP -

Any hopes of fixing this OR can I help fix it.

My other option is porting my TEXTPATTERN site to WORDPRESS….

GOD FORGIVE ME IF I DO!

:-)


On the World Wide Web since Day 1 – Editor/Creator – Coffeecrew.comCoffee.bc.ca
Twitter – Twitter.Com/CoffeeCrew -

Offline

#3 2019-02-15 13:06:05

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: 4.71 to 4.72

colin99 wrote #316606:

Ah yes – this is txplib_misc.php rearing it’s ugly head again with things like eval()
setting off alarms with my ISP -

This eval() has always been there, fwiw, but ISP are getting zealous these days. Something is on our TODO list, but I’m not sure we can totally get rid of it — <txp:php /> uses eval() as well. Weirdly, it does not seem to bother ISP.

Offline

#4 2019-02-15 14:42:07

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: 4.71 to 4.72

I don’t suppose there are workarounds to this like updating zipped and then unzipping on the server, uploading under another file type and renaming, or uploading edited and then editing the function back in?


TXP Builders – finely-crafted code, design and txp

Offline

#5 2019-02-15 15:02:59

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: 4.71 to 4.72

Or dirty hacks which actually have merit until such time as we can officially find a way to evaluate PHP code without evaluating it…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2019-02-15 15:23:45

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: 4.71 to 4.72

Although it’s WP-specific this article on security pitfalls lists a series of potential attack vectors in PHP and what can be done about them. Things don’t look good for eval() so if the very act of uploading a file via FTP in our base package that contains the eval() function is causing some hosts to automatically stop that file being executed, we’re sunk.

Sidestepping <txp:php>, even if the eval() is off the critical path and is done once when a (sanitized) plugin is installed – and the user is happy it’s from a trusted source because we offer the verify step first anyway – and the plugin is then ‘compiled’ and put in a directory for inclusion via include_once() it’s still no guarantee.

As it quite rightly states in the article, PHP’s include() / require() is a thinly-disguised eval() anyway. At least if the code to be evaluated is stored in the DB it’s a smaller target – usually behind two passwords (host and DB) – whereas if we’re arbitrarily using include() to directly bring in files from a plugins directory there’s nothing to stop anyone with access to the server – even from a vulnerability in another CMS such as WordPress – from dropping a file in there and having it executed.

Of course, we’d mitigate that by only allowing registered and active plugins to be included, so it’s not all bad and we wouldn’t just include() anything in the dir willy nilly… oh wait, we do that with the plugin_cache_dir, right?

What I think we need to do here to address this is to tighten up the concept of the plugin_cache_dir. Make it perhaps so it’s a mandatory option and that only registered plugins can run from that directory. Yes, we lose the immediacy of just dropping a file in there and having it evaluated on the fly, but we gain a modicum of security by showing in the Plugins panel all DB-registered and unregistered plugins that reside in this directory.

Then it’s a simple act of selecting the ones you want to register from the list, doing a multi-edit on them to bring the metadata into the DB and make them available for use. This also overcomes the final hurdle of plugin_cache_dir plugins: no install/uninstall routine hooks. Saves us a lot of hacky code to auto-load DB strings and stuff on the fly, plus makes it simpler for plugin authors as they don’t have to worry about “what if my plugin hasn’t been installed in the DB”? It will be. It has to be registered, at which point it is subject to plugin lifecycle hooks.

Plus, when a plugin is registered, we copy its code into the DB and/or make a hash of it. Any alteration to the underlying code in the file can then be flagged in the Modified column, giving a nice way of seeing if edits have been performed. And if you have made the changes yourself and are happy with them, we could offer a “rehash” multi-edit option which takes the code off disk and puts it in the DB and/or recalculates the hash so that the warning doesn’t show until next time the file is altered by the admin or an unscruplous outsider.

Plugins that are installed in a regular manner from .txt file via Admin->Plugins aren’t affected. The installation could work as usual. The code from the verified plugin would just be converted to a valid file that is include()able, dropped into the plugin cache directory and automatically marked as registered in the DB. As far as the user is concerned: no change. The only change would be for people who use the plugin_cache_dir as a dumping ground for plugins to autorun. They would no longer be able to do that and would have to do a one-time ‘registration’ of these externally-uploaded files before they would be used inside Txp.

EDIT side note: including files from the file system may well be a bottleneck on plugin-heavy sites or those with spinning disk. Compare one DB query to load_plugins() from a single query that gets all the code out of the database and evaluates it vs disk access on 50 plugins, each of which will be required to go through include(). We’d need some benchmarks here.

Last edited by Bloke (2019-02-15 15:37:56)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#7 2019-02-16 21:49:36

colin99
Member
Registered: 2005-11-15
Posts: 65

Re: 4.71 to 4.72

Bloke wrote #316613:

Well said – great explanation.

What I am hearing here is that Wordpress and Joomla are likely as guilty in incorporating some of this “trick knee” PHP commands… Yes?

<i>
bq.. Although it’s WP-specific this article on security pitfalls lists a series of potential attack vectors in PHP and what can be done about them. Things don’t look good for eval() so if the very act of uploading a file via FTP in our base package that contains the eval() function is causing some hosts to automatically stop that file being executed, we’re sunk.</i>


On the World Wide Web since Day 1 – Editor/Creator – Coffeecrew.comCoffee.bc.ca
Twitter – Twitter.Com/CoffeeCrew -

Offline

#8 2019-02-16 22:16:36

colin99
Member
Registered: 2005-11-15
Posts: 65

Re: 4.71 to 4.72

colin99 wrote #316625:

Bloke wrote #316613:

Well said – great explanation. Very good read

What I am hearing here is that Wordpress and Joomla are likely as guilty in incorporating some of these “trick knee” PHP commands… Yes I see that they are?

If you must use eval in your program, you should go out of your way to make sure that you don’t allow arbitrary user input to be passed into it. And if you must allow arbitrary users access to the inputs to eval, confine what they can do via a blacklist of commands you don’t let them run, or (better, but far harder to implement) a whitelist which is only the commands you consider safe. Better still, only allow a small number of specific parameter changes, like only validated integers.</pre>

p.


On the World Wide Web since Day 1 – Editor/Creator – Coffeecrew.comCoffee.bc.ca
Twitter – Twitter.Com/CoffeeCrew -

Offline

Board footer

Powered by FluxBB