Crazy Amount of Fake Registrations Despite Q&A, Recaptcha, and Vertical Icons

[Arantor]

Every time there is a critical DB error, an email is supposed to be sent to the admin. The time of the last email is recorded in Settings.php to avoid sending too many.

There is a race condition whereby two errors too close together will cause the file to be wiped in the middle of this process.

There are other issues with not upgrading, like a lack of PHP 5.5+ compatibility.

ninja'd

[own3mall]

it is actually not really simple to patch 1.1.x nor do we intend to do so, even if it was... as I said, 1.1.1x is sunset already.

it empties because of a race condition with the error status getting written to the settings.php file when it was already being written to by another error.

for the most part, it's not a common error...

It would be nice if serious issues like this would be patched... even though 1.1.x is considered sunset (a lot of people are still going to use SMF 1.1.x due to compatibility issues on SMF 2.x).  I guess I'll have to look into why the file might get emptied and see if I can modify some code to prevent that from happening. 

[Arantor]

SMF 2.0 has been out for over three years. It's not like there is some surprise or gotcha that this is going to be a thing.

[own3mall]

There is a race condition whereby two errors too close together will cause the file to be wiped in the middle of this process.

Shouldn't you place an exclusive lock on the file handle to prevent that from happening?  Seems like an avoidable issue to me.

There are other issues with not upgrading, like a lack of PHP 5.5+ compatibility.

Don't even get me started on that... anything after PHP 5.3.X is a clusterf*** disaster.  You don't deprecate old code simply because you want everyone to write it a new way.  I know of a lot of old applications that STILL work great but will not be rewritten for proper PHP 5.5+ support.  Luckily, those of us running older linux servers won't have that problem since we can keep PHP 5.3.x. and our old working simple applications.

SMF 2.0 has been out for over three years. It's not like there is some surprise or gotcha that this is going to be a thing.

No, but again, I have customized my forums like crazy using older themes which are not compatible with SMF 2.0.x.  As a result, I can't upgrade.  It's not a choice.  The forums will never behave or look like they did in 1.1.X, so for me, it's a no-go.

[Kindred]

Sorry, I think you seem to have some misunderstanding as to what the term "sunset" means...

It may be an avoidable issue, which has since been solved in future versions...  But it's not that simple in 1.1.x.
As for php5.5+, I disagree with your assessment of a cluster....


I would recommend that you start looking at themes for 2.0.x, or look at the beta for 2.1 and consider designing a theme for that, since 1.1.x will not even be receiving security releases past 1.1.20

[Arantor]

Actually, the changes in PHP beyond PHP 5.3 are for good reason, and not just because arbitrary annoying developers. Just because you may not know what they are or may not understand them does not make them any less valid.

The fact that PHP itself has bugs, there are ones in 5.2 that won't be fixed that can cause a DOS to occur alone should be a reason for keeping up to date.

Remember, we're talking about a piece of software older than Windows Vista right now. SMF 1.1 debuted in 2006, it's almost 2015. There are more improvements under the hood than one bug fix.

[own3mall]

Can anyone think of a reason why this wouldn't work to prevent the Settings.php file from being blank in the future?

Changes Made To: \Sources\Admin.php
Original Code:

Code Select Expand


        // Blank out the file - done to fix a oddity with some servers.
$fp = @fopen($boarddir . '/Settings.php', 'w');

// Is it even writable, though?
if ($fp)
{
fclose($fp);

$fp = fopen($boarddir . '/Settings.php', 'r+');
foreach ($settingsArray as $line)
fwrite($fp, strtr($line, "\r", ''));
fclose($fp);
}


Changed Code:

Code Select Expand


        // Not needed anymore
// Blank out the file - done to fix a oddity with some servers.
// $fp = @fopen($boarddir . '/Settings.php', 'w');

$fp = fopen($boarddir . '/Settings.php', 'a+');

if($fp && flock($fp, LOCK_EX)){ // Obtain an exclusive lock
// Truncate the file and recreate the Settings.php file.
ftruncate($fp, 0);

// Write each setting to the file
foreach ($settingsArray as $line){
fwrite($fp, strtr($line, "\r", ''));
}

// Remove the lock
flock($fp, LOCK_UN);

// Close the file handle
fclose($fp);
}else if($fp){
// We were able to open the settings file
// However, we didn't get an exclusive lock.
// Just close the file handle
fclose($fp);
}


[Arantor]

You mean other than the fact SMF 2 did that and it still happened because LOCK_EX is not actually quite so exclusive?

[own3mall]

Well, considering I've used exclusive locks with files running from a multi-threaded php script using pthreads, I'd say exclusive locking works just fine since I tested it with 500 threads for a server query utility I wrote...

And if you looked at my code, the settings file itself is not deleted unless an exclusive lock is granted.

[Arantor]

Yes, yes I realise this. This is the kind of thing SMF 2.0 tries to do, only it doesn't work there either.

The thing is... even if this solves it perfectly, the team still isn't going to update 1.1.x.

[own3mall]

even if this solves it perfectly, the team still isn't going to update 1.1.x.

It's a good thing I'm here to do it then. 

[Biology Forums]

Posting for future consideration, thanks own3mall.