Marco's SQL Injection - LFI Interceptor plugin Topic is solved

[John666]

I have used this plugin very successfully on 4 Joomla sites for some years, and have been very satisfied with it. However, I recently had an unusual problem that I cannot understand.

All my Joomla 3.9.5 sites all rununder PHP 7.2.17 and use the latest version 1.6 of the Marco's plugin. Three of sites are on one server, and one is on a different server. The one on the different server is the site that has experienced the following problem.

After several years of perfect operation, and for no reason apparent to me, I was suddenly blocked from the site - no admin panel access, no cpanel access and no access to the front end. The error message given on the front end can be seen in the attached image. I eventually accessed the site using login detains from another superadmin and disabled the Marco's plugin. Everything then returned to normal.

Any thoughts on what might be happening would be appreciated.

[Per Yngve Berg]

The plugin is not compatible with the version of php.

[John666]

Thanks for the reply - valuable information. Please could you tell me where you found that information.

So am I just "getting away with it" on the other 3 sites on another server?

[Slackervaara]

Take a look at this post. Can be easy to change the code right:
viewtopic.php?t=956778

[Webdongle]

Use Marco's sql plugin 1.6 on a site php 7.2.17 no problem

[John666]

Thanks to all. Yes, I am using v 1.6 on three sites without any problem. But ona fourth site on a different server there are serious issuses.

The code is indeed easy to alter once you have the information. The change is:

Change the constructor:
open plugins/system/marcosinterceptor/marcosinterceptor.php
and change line 15 from
function plgSystemMarcos interceptor( &$subject, $config ){
to
function __construct( &$subject, $config ){

(Thanks to the author of this change for making this code available.)

Great, all fixed!

[Webdongle]

So the problem was in the plugin or the problem was the server and the plugin was altered to match the server?

[John666]

I'm not too sure but it seems to be the case that the server where the problem was experienced is less tolerant of warnings regarding imperfect code - which nevertheless works. If you look at the plugin on the Joomla extensions directory - at the bottom - there are a number of comments regarding this issue. It may also depend on the version of php used - I am using php 7.2.17 (on both servers).

Sorry I can't tell you more - I don't fully understand this myself. But I can tell you that the fix does work.

[sozzled]

@Webdongle: here's a hint.

Whenever we read in an error message "Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; <extension> has a deprecated constructor in <filename> on line n" it's a tell-tale sign that the website is using PHP 7.x. It is also a sign that the <extension> was written for PHP 5.

While this error, itself, may not necessarily be fatal and the <extension> is unable to complete execution, the failure to complete running the <extension> may be a dependency for something else—something really important—(e.g. session management) to happen. It's that "other" thing that causes everything to go pear-shaped.

So, the problem starts with software designed in a particular way—in a way that was acceptable if the website used PHP 5—and when that software hits a brick wall when the website environment changes to use PHP 7. It's not a "server thing", per se. One can spend a few hours (as I have done) reading the PHP manual.

[Webdongle]

@sozzled here is my conundrum
I also have a site running on php 7.3.3 and marco's interceptor 1.6 but that does not show the code in 1.6 as deprecated. And runs OK

[Slackervaara]

What about error reporting?

[sozzled]

As @Slackervaara writes, these warning may not necessarily appear on a web page as see in the screenshot image in the OP but they're probably being logged in the error_log (and you'll see the error_log file grow in size over time) especially if you have the error reporting level set above "None". I can't say what happens with this particular extension. I can comment in relation to several other extensions I've used and the symptoms in the OP's case indicate the same cause (if not with that extension). Make sense?

A lot of these PHP 7 incompabilities lie undetected (as far as we humans are concerned) while the site logs them in the error_log.

Perhaps the version of Marco's SQL Injection - LFI Interceptor plugin is not what the OP thought it was? I can't say. Further, the listing on the JED (shows v 1.4) has not been updated in five years and the JED says that the extension doesn't use the Joomla update mechanism. According to the developer's website, v1.6 was released 3½ years ago (in November 2015) which pre-dates PHP 7. (PHP 7.0 was released in December 2015)

[Webdongle]

So as deprecated code can be legitimately used something on the server was preventing being used. Therefore there was nothing wrong with the code as such ... but it had to be changed to to work on the server (or with other software) because the legitimate code was prevented from working.

[sozzled]

Yeah ... kind of. There's nothing wrong with using crappy code. That's a choice that people can make. On the other hand, every time that piece of code is executed, it'll fail and (depending on the error reporting level) each failure will be logged in the error_log. And the error_log will grow over time. And, of course, unless you tell your backup service to not backup this file, that file will be added to the backup (and, of course, that's extra work).

Better to fix up the bad PHP (takes a few moments) than leave it hanging around for a "gotcha" moment, eh?