News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

[minor bug] certain authentication cookies badly handled

Started by uglybunz, October 02, 2013, 09:50:41 AM

Previous topic - Next topic

uglybunz

SMF version: 2.0.5, no mods or themes or add-ons, set to defaults (caching etc. using file caching)
PHP: 5.3.27
mySQL: 5.5.33
httpd: Apache 2.2.25
UTF-8: yes
OS: FreeBSD 8.2

Scenario: When testing a new SMF converter it was necessary to wipe a previous SMF installation and install a fresh one. Both installations used the default Cookie Name of 'SMFCookie405'.

After re-installing and re-populating, some users were unable to login or use the 'Forgot password' mechanism. When they entered their username they received this error:

    An Error Has Occurred!
    Your session timed out while posting. Please go back and try again.

The following items were logged by SMF when logins (using good credentials) were attempted by those experiencing the problem:

Guest
September 30, 2013, 22:54:09
47f704b6f3a98b57d8eb439ef526c15a
Type of error: Undefined
hxxp://smf.obfuscated.org/index.php?action=login
8: Undefined index: permissions
File: /usr/home/ewebb/smf-experimental/Sources/Security.php
Line: 831

and

Guest
September 30, 2013, 22:54:09
47f704b6f3a98b57d8eb439ef526c15a
Type of error: General
hxxp://smf.obfuscated.org/index.php?action=login
2: in_array() expects parameter 2 to be array, null given
File: /usr/home/ewebb/smf-experimental/Sources/Security.php
Line: 831

The users were unable to log in, despite offering good credentials.

The problem was traced to being caused by the fact that the users experiencing the problem had authentication cookies that had been issued by the previous installation of SMF, and were hence unrecognised by the new installation. Clearing the cookies solved the problem.

While the above may seem like an unusual scenario, anyone restoring an SMF installation from a backup is likely to cause similar issues for their users who authenticated after the backup was made, as their cookies will no longer be valid.

So, is it a bug? In my opinion it is, as SMF could easily recover from the above situation by clearing the problematic cookie and logging something more meaningful in the log, in case someone is trying to hack authentication in some way. It seems to me that the above scenario was not anticipated by SMF's programmers.

Current behaviour: Login attempts or password reset attempts by users with 'bogus' cookies cause inexplicable authentication errors or failures. Undefined or meaningless errors are logged. The users experiencing the problem have no idea why they can't log in, especially if they are unaware that maintenance work has been carried out.

Suggested behaviour: SMF should recognise when an invalid cookie with the 'correct' Cookie Name is presented, and log an obvious security message and the IP of the user. Then it should clear the problematic cookie and allow the user to proceed to authentication.

To reproduce:

Method 1: set up a user jobloggs/pass in a fresh installation of SMF, then authenticate 'forever' as that user. Don't log off. Using a different browser now re-initialise the SMF and set up jobloggs/pass again. Try to log in or reset the password using the original browser with the original authentication cookie.

Method 2: Log off a non-admin account and make a backup of your SMF installation. Now log into that account 'forever' as the non-admin user. Don't log off. Using a different bowser, restore your backup of SMF. Now try to log in or reset the password for the non-admin account using the original browser with the (now bogus) authentication cookie.

Thanks for the great software and phenomenal support!

uglybunz

Arantor

Than you for the report - I'm sorry I didn't get back to you before about this, but it's been a bit manic here.

You're right, the behaviour was not entirely anticipated. Part of the problem is the session table's inconsistent state, and that it shouldn't really be taken in a backup in any case.

We will look into this and look at exactly what we can do to patch it over the coming days.

uglybunz

Thanks, but there's no need to go to any trouble on my behalf. I just thought that I should report it, as when I was researching the error messages that it threw up I discovered that it has bitten a number of people over the years, usually after restoring backups.

No-one seems to have made the connection to the cookies, so it was just a weird problem that only affected a few users, couldn't easily be debugged, couldn't be replicated, and disappeared after a few days anyhow, as cookies expired and browser caches got cleared. So the discussions all fizzled out without resolution and it never got nailed down.


pveatx

It looks like it...

I've upgraded my forum also and run into these errors frequently as well. Is it possible to provide an update to version 2.0.11 to really fix this issue? The original poster suggests ways of solving it...

I have users returning quite often, and they can't log in until their cookies have been cleared.

Peter

Kindred

please start your own thread in the SUPPORT area...  since your issue is completely unrelated unless you are frequently taking and restoring backups between user sessions which is what caused the original report.

and if you ARE doing that.... WHY would you be doing that?
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

pveatx

Kindred,

My issue is exactly as described in the first post in this thread. I converted a forum from 1.11.21 to 2.0.11 on January 15th 2016. The forum is for a car afficionado website. I have paying members who return infrequently, e.g. to renew their membership. There may be months between accesses. Those that return after last having been on the old forum prior to the transfer occasionally get locked out, just as described in post 1.

I get lots of entries in the log, referring to Security.php, line 831.
I get users unable to log in with their valid credentials, and being locked out after three attempts.

I'd like a solution as follows:

QuoteSo, is it a bug? In my opinion it is, as SMF could easily recover from the above situation by clearing the problematic cookie and logging something more meaningful in the log, in case someone is trying to hack authentication in some way. It seems to me that the above scenario was not anticipated by SMF's programmers.

Current behaviour: Login attempts or password reset attempts by users with 'bogus' cookies cause inexplicable authentication errors or failures. Undefined or meaningless errors are logged. The users experiencing the problem have no idea why they can't log in, especially if they are unaware that maintenance work has been carried out.

Suggested behaviour: SMF should recognise when an invalid cookie with the 'correct' Cookie Name is presented, and log an obvious security message and the IP of the user. Then it should clear the problematic cookie and allow the user to proceed to authentication.

I grant you it's an infrequent occurrence, but in my case it will lose me paying subscribers...

Peter

Kindred

but your issue is a ONE TIME occurrence. The situation described by the OP ONLY happens after a backup and restore...  If you only did it once, then  wile, it may happen, it is not an ongoing thing.

Additionally...  the action described might address the issue  GOING FORWARD but would have limited or no effect on PREVIOUSLY caused triggers. Additionally, because this is such an infrequent occurrence, it MIGHT be addressed in 2.1, but almost certainly will not be addressed in 2.0.x

Your solution?   Change the cookie name.
That will FORCE everyone to log in with a new cookie and the issue won't happen.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

pveatx

Quote from: Kindred on February 17, 2016, 06:40:12 AM
but your issue is a ONE TIME occurrence. The situation described by the OP ONLY happens after a backup and restore...  If you only did it once, then  wile, it may happen, it is not an ongoing thing.

It's a ONE TIME occurrence potentially PER USER. I've seen it happen around 8 times so far... but I'll take your suggestion of changing the cookie name.

You could however display a slightly more emphatic response to a real issue on real forums that upgrade from one SMF version to another... which I'm sure is not uncommon.

Peter


Kindred

you have missed my point...

it is a one time occurrence.  It ONLY happens if you take a backup and then restore it with active sessions in the table and don't change the cookie name (most of the time, a large upgrade from major to major version DOES change the cookie name and upgrades from minor to minor version can and should be doing using the patch files in the package manager  not the large upgrade)

Yes, this could affect multiple users... but only as this one time occurrence  it won't happen again unless you repeat the above steps again...

So, while it technically is a bug...  there is a simple work around  --- just rename the cookie.


Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Illori

Quote from: Kindred on February 18, 2016, 07:50:59 AM
it is a one time occurrence.  It ONLY happens if you take a backup and then restore it with active sessions in the table and don't change the cookie name (most of the time, a large upgrade from major to major version DOES change the cookie name and upgrades from minor to minor version can and should be doing using the patch files in the package manager  not the large upgrade)

since when? usually when done running upgrade.php if you were already logged in you still are logged in, if the cookie name was changed then you would get logged out. i dont even see mention of cookiename in upgrade.php.

Kindred

every time I have done a major upgrade 1.0 to 1.1 to 2.0 to 2.1, the cookie has changed
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Illori

i have not checked in Settings.php but i am pretty sure it has never changed or logged me out after doing an upgrade. upgrade.php would control that and there is no code in it that would change the cookie at least in SMF 2.1.

in upgrade.php for SMF 2.0 upgrade.php has the following code

// !!! Maybe change the cookie name if going to 1.1, too?

// Update Settings.php with the new settings.
changeSettings($changes);
nothing there changes the cookiename

Advertisement: