"Function name must be a string" in ...../libraries/loader.php

[vittoz]

Chiedo scusa se l'argomento è già stato trattato; ho gia provato a cercare su questo forum ed anche  altrove, ma non trovo nulla che io riesca a mettere a frutto.
Scenario:

Utilizzo Joomla 3.6.2 . Sono stato hackerato ed ho eliminato tutto ciò che ho trovato con un antivirus che reputo buono (forse non posso citare la marca in questo contesto?).  Cito  questo fatto per trasparenza ma credo che il problema dipenda da altro; forse estensione obsoleta?  Il problema si è manifestato prima di quanto si manifestasse il malware. Tuttavia non so da quanto tempo il malware fosse "silente".
L'aggiornamento da 3.6.2.  a 3.7  falisce. Speravo di cavarmela in questo modo. Non so se il problema sia correlato.
Ho fatto una diff ricorsiva (lavoro da linux) su tutti i file del sito e di una fresh-install della versione e non trovo differenze se non i file aggiunti al sito (estensioni, immagino....)
Problema:

Ho un errore PHP che mi si manifesta solo (mi pare) in Configurazione globale e che causa l'interruzione della generazione della pagina che pertanto appare sul browser parzialmente. Ho attivato $error_reporting = 'E_ALL';  in configuration.php.
Stack Trace:

0 Function name must be a string
Call stack
#
Function Location
 Function Location
1JApplicationCms->execute()<RD>/administrator/index.php:51
2JApplicationAdministrator->doExecute()<RD>/libraries/cms/application/cms.php:257
3JApplicationAdministrator->dispatch()<RD>/libraries/cms/application/administrator.php:152
4JComponentHelper::renderComponent()<RD>/libraries/cms/application/administrator.php:98
5JComponentHelper::executeComponent()<RD>/libraries/cms/component/helper.php:380
6require_once()<RD>/libraries/cms/component/helper.php:405
7ConfigControllerDisplay->execute()<RD>/administrator/components/com_config/config.php:31
8ConfigViewApplicationHtml->render()<RD>/components/com_config/controller/display.php:104
9JViewHtml->render()<RD>/administrator/components/com_config/view/application/html.php:78
10include()<RD>/libraries/joomla/view/html.php:148
11ConfigViewCmsHtml->loadTemplate()<RD>/administrator/components/com_config/view/application/tmpl/default.php:101
12include()<RD>/components/com_config/view/cms/html.php:143
13JLayoutHelper::render()<RD>/administrator/components/com_config/view/application/tmpl/default_database.php:14
14JLayoutFile->render()<RD>/libraries/cms/layout/helper.php:72
15include()<RD>/libraries/cms/layout/file.php:121
16JFormField->__get()<RD>/layouts/joomla/content/options_default.php:48
17JFormFieldList->getInput()<RD>/libraries/joomla/form/field.php:402
18JFormFieldDatabaseConnection->getOptions()<RD>/libraries/joomla/form/fields/list.php:58
19JDatabaseDriver::getConnectors()<RD>/libraries/joomla/form/fields/databaseconnection.php:46
20class_exists()<RD>/libraries/joomla/database/driver.php:222
21spl_autoload_call()
22JLoader::_autoload()
23JLoader::_load()<RD>/libraries/loader.php:568
24include()<RD>/libraries/loader.php:599





Qualsiasi suggerimento è gradito anche se generico. Non conosco l'architettura implementativa Joomla.  Posso debuggare e modificare il PHP se  ciò servisse  a diagnosticare la causa.
Immagino che il rifacimento del sito sarebbe una soluzione ideale. Forse per il sito ma non per il mio tempo ed il mio know-how.
Grazie !!!

[Ahmed Salvini]

mi sa che non hai eliminato tutti i problemi o come dici tu hai estensioni obsolete.

Nel primo caso puoi leggere i post in testa alla sezione, nel secondo basta che le controlli una ad una.

L'errore è abbastanza indicativo e solitamente in joomla non si hanno questi tipi di errore.

La funzione location fa pensare a qualche redirect. Joomla che io sappia non la usa e un antivirus difficilmente la segnala poichè un redirect non è di per se malevolo

[Alex21]

Potrebbe essere qualcosa di semplice.  Leggi: http://www.webdeveloper.com/forum/showthread.php?140704-RESOLVED-Fatal-error-Function-name-must-be-a-string   e
http://stackoverflow.com/questions/1611709/php-error-function-name-must-be-a-string
Che si vede nei log del server?
Ciao!

[vittoz]

WOW!!!!  sono commosso e stupito dalla tempestività e cordialità del vostro aiuto.
Ora mi metto subito al lavoro e tento di mettere a frutto le vostre ottime indicazioni !!!
GRAZIE !!!!

[vittoz]

Chiedo scusa per non aver formattato diligentemente il Call-Stack.  La linea  " Function Location" sarebbe lo "header" della tabella e indicherebbe il path+lineNumber della call.   

[Ahmed Salvini]

Potrebbe essere qualcosa di semplice.  Leggi: http://www.webdeveloper.com/forum/showthread.php?140704-RESOLVED-Fatal-error-Function-name-must-be-a-string   e
http://stackoverflow.com/questions/1611709/php-error-function-name-must-be-a-string

ho letto ma non ho capito cosa centri con joomla e col suo problema

[vittoz]

Credo che per "log del server" si possano intendere i 2 log di apache: error & access.
Ebbene:

• "error" non segnala nulla, solo l'attività normale dei demoni. 
• "access"  pare tutto ok: HTTP= +0200 sempre

Inoltre:

• Log di PHP: non genera alcun errore a fronte della generazione della pagina incriminata.  Pur avendo impostato <error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT> in php.ini   e display_errors = On   e log_errors = On

......questo è uno degli aspetti che mi mette in crisi ....

[vittoz]

Leggendo il commento di Ahmed Salvini vorrei precisare che mi basterebbe localizzare il problema. Scoprire eventualmente quale estensione fosse  (ed in teoria dovrebbe esserlo al 100% ..... ) per me sarebbe una ottima soluzione!!!

Sarei capace anche di mettere una (brutta) pezza al PHP ...... ma non è questo il mio problema!

Aggiungo il fatto che sto debuggando su un server tutto mio (ed in LAN) e quindi posso farci quello che voglio )
......mi basterebbe  saperlo fare ....  )   hahahaha

[Alex21]

ho letto ma non ho capito cosa centri con joomla e col suo problema

Penso che c'entri perché non arriva una stringa dove è attesa.
Dunque, la versione di joomla è 3.6.2. L'ultimo file dello stack è:  24include()<RD>/libraries/loader.php:599.
Dovrebbe essere qui:

Codice: [Seleziona]

596 // Load the file if it exists.
597 if (file_exists($path))
598 {
599 return include $path;
600 }. $path non è quello atteso o non esiste, sembra.
Ciao!

[Alex21]

......questo è uno degli aspetti che mi mette in crisi ....

Allora l'errore viene recuperato da joomla che fa uscire anche il messaggio.
Visto che puoi fare quello che vuoi, potresti esaminare il valore di $path (vedi msg a A. Salvini) inserendo un var_dump($path) oppure un user_error() alla riga :599, magari abilitando xdebug, cioè decommentando la riga del php.ini  dove c'è xdebug, così ti esce anche lo stack da php.
Se il problema viene da un precedente hackeraggio del sito, con un (bel) po' di lavoro si dovrebbe riuscire a risalire al file alterato, che non dovrebbe essere troppo lontano dall' ultimo dello stack.
Ciao!

[vittoz]

 Ringrazio tantissimo per i cordiali consigli!!!
Qualcosa del genere l'avavo già fatto:  avevo inserito: 

Codice: [Seleziona]

file_put_contents('<RD>/libraries/MyOwnPHP.log', $path . "\n", FILE_APPEND | LOCK_EX); // Debug 20170511 
dentro lo "if" e prima del return $path.
Al caricamento della pagina Joomla ottengo molte righe, eccole omettendoo le prime:

Codice: [Seleziona]

…...omissis……..
<RD>/libraries/joomla/cache/storage/memcached.php
<RD>/libraries/joomla/cache/storage/apc.php
<RD>/libraries/joomla/cache/storage/redis.php
<RD>/libraries/joomla/cache/storage/wincache.php
<RD>/libraries/joomla/cache/storage/cachelite.php
<RD>/libraries/joomla/cache/storage/xcache.php
<RD>/libraries/joomla/cache/storage/apcu.php
<RD>/libraries/joomla/session/storage/memcache.php
<RD>/libraries/joomla/session/storage/none.php
<RD>/libraries/joomla/session/storage/memcached.php
<RD>/libraries/joomla/session/storage/apc.php
<RD>/libraries/joomla/session/storage/wincache.php
<RD>/libraries/joomla/session/storage/xcache.php
<RD>/libraries/joomla/database/driver/sqlazure.php
<RD>/libraries/joomla/database/driver/sqlsrv.php
<RD>/libraries/joomla/database/driver/oracle.php
<RD>/libraries/joomla/database/driver/pdo.php
<RD>/libraries/joomla/database/driver/bclass.php
<RD>/libraries/joomla/document/error.php
<RD>/libraries/cms/html/string.php
Pertanto assumerei che il PHP termina con l'errore detto  ritornando,  oppure dopo (?) aver ritornato, il path di "string.php"
Il modulo <RD>/libraries/cms/html/string.php pare regolare al 100% in quanto è identico (esito di diff) all’omologo di una fresh install della stessa versione.
Ebbene qui rimango in difficoltà perché:

• la stringa ritornata pare corretta; almeno se interpretata come stringa pura e semplice.
• queste operazioni vengono fatte in un modulo che chiamandosi “loader”  immagino sia finalizzato a caricare dinamicamente del codice PHP …...forse per l’esecuzione    MA NON lo so ; non conosco l’implementazione di Joomla.  Tuttavia temo che se i moduli detti sono caricati in modo dinamico e se si  dà loro il controllo (ipotesi) allora forse lo stack trace non conterrà mai la computazione sino al suo vero abort.   Ma queste sono solo mie supposizioni di Joomla-e-PHP-ignorante.
• Eliminando dal filesystem il modulo “string.php”, la computazione cessa di generare output apparentemente come (al punto di …..) prima, ma ovviamente senza generare alcun errore !

In sostanza non riesco a concepire il punto in cui si ha l’errore e temo che l’indicazione che fornisce il PHP sia purtroppo vaga causa specificità del codice Joomla proprio in “quel punto”……………  sbaglio?

[Ahmed Salvini]

In sostanza non riesco a concepire il punto in cui si ha l’errore e temo che l’indicazione che fornisce il PHP sia purtroppo vaga causa specificità del codice Joomla proprio in “quel punto”……………  sbaglio?
----------------------------------------------------------------

perchè non è procedurale quindi non esiste il "punto" ma tanti punti.
Hai letto gli articoli in evidenza nella sezione sicurezza? Correre dietro al malware spesso non è una buona idea, vince lui

[Alex21]

file_put_contents(ecc. ecc.)  mi sembra una bella idea, però l'uscita non ha i numeri di linea, invece credo che sarebbe proprio utile sapere cosa ritorna con quel $path. 

Potrebbe essere un link simbolico (lavoro hacker). Non è una stringa di percorso valida per joomla.
Potrebbe essere un percorso che non c'è più perché lo hai già ripulito.
Potrebbe ...

Tornando al loader.php, il $path interessato si può leggere alla riga :599  ma anche alla :594  e anche nel metodo chiamante, riga :568 come nel tuo primo stack.  Quest'ultima è dentro un foreach() quindi se alla :597  si mette  echo  self::_load(substr($class, strlen($prefix)), $lookup); dovrebbero uscire tutte, compresa quella critica che provoca errore.
Insomma, buon lavoro purtroppo.
Ciao!

[vittoz]

 Ringrazio delle osservazioni e ammetto di non essere certo d’averle capite al 100%. Comunque tento una risposta che spero sia abbastanza pertinente.   Commento la frase seguente:

file_put_contents(ecc. ecc.) mi sembra una bella idea, però l'uscita non ha i numeri di linea, invece credo che sarebbe proprio utile sapere cosa ritorna con quel $path.

• L’elenco di path che ho postato rappresentano il valore della variabile $path durante la computazione.
• La stringa <RD> l’ho sostituita io alla root directory del sito per non aggiungere “rumore” inutile al il post.
• Non mi è chiaro in che senso l’output dovrebbe avere numeri di linea. Le linee di output rappresentano dei dati “passivi” per il  PHP e NON (ancora) il codice interpretabile.
• La primitiva “include” trasforma tali path nel codice PHP che viene restituito al chiamante di questo metodo _load().
• Non riesco a capire chi sia il chiamante del metodo _autoload (). Lo stack trace non dice dove stia….ora cerco meglio....
• Immagino e temo  che dal qualche parte vi sia un passaggio del controllo ai moduli  PHP inclusi a partire dai vari path. E’ questo che mi crea molta incertezza perché mi pare renda l’individuazione del codice in esecuzione più problematico da parte dei log di  debug del PHP.   

[Ahmed Salvini]

Questo è quello che succede https://api.joomla.org/cms-3/graph_class.html
Questo è quello che puoi fare http://forum.joomla.it/index.php/topic,117151.0.html e ti garantisce files di Joomla puliti.
Per eventuali script in files inseriti (che potrebbero contenere shell pper ricostruire il malware o per guadagnare l'accesso) l'unica è utilizzare un tool che compari un pacchetto pulito con uno dubbio.

[vittoz]

Grazie ancora per i suggerimenti.
la pagina suggerita

/forum.joomla.it/index.php/topic,117151.0.html

mi è di grande aiuto !!!
 
Purtroppo non riesco ad intuire il significato della pagina

https://api.joomla.org/cms-3/graph_class.html

Vi trovo solo un'animazione con un loop indefinito e non capisco il significato inteso.
Immagino che Ahmed Salvini intendesse suggerirmi di studiare le API di Joomla per intuirne il funzionamento. Sbaglio?

[vittoz]

MI correggo: ho capito cosa indica la url "https://api.joomla.org/cms-3/graph_class.html" !!!
MI sono accorto che si trattava di un difetto del mio browser e ne ho utilizzanto un altro che mi visualizza correttamente il grafo dell'ereditarietà  delle classi.

OK! Grazie ! appena ho due lustri di tempo me lo studio