• Welcome to Simple Machines Community Forum. Please login or sign up.
October 16, 2021, 03:34:17 PM

News:

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


[4244]SMF 2.0 RC3 - Obfuscation of session variable name breaks integration

Started by Orstio, April 01, 2010, 05:46:51 PM

Previous topic - Next topic

Nao 尚

Norv has set a RC4 flag on this bug report so I guess he considers it should be fixed as a priority.

I myself had many problems in the past with subdomains, but they were mainly due to security violation when submitting forms through Ajax from one subdomain to another. Now, I don't know if this bug is related (I haven't got much time to look into it either.) Is it something that happens because the session variable can't be put into the login form from the non-forum subdomain? Or something that happens AFTER posting the form? Or non-matching session variables?
I can't even see a session var in your distant form...

BTW, your password is no longer active.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Norv

To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

MultiformeIngegno

Quote from: Nao on June 07, 2010, 12:23:49 PM
Norv has set a RC4 flag on this bug report so I guess he considers it should be fixed as a priority.
8)

Quote from: Nao on June 07, 2010, 12:23:49 PM
I myself had many problems in the past with subdomains, but they were mainly due to security violation when submitting forms through Ajax from one subdomain to another. Now, I don't know if this bug is related (I haven't got much time to look into it either.)
Yeah I've read 'em (language editor), don't remember if they was similar..

Quote from: Nao on June 07, 2010, 12:23:49 PM
Is it something that happens because the session variable can't be put into the login form from the non-forum subdomain? Or something that happens AFTER posting the form? Or non-matching session variables?
I can't even see a session var in your distant form...
Look here: http://www.simplemachines.org/community/index.php?topic=373342.msg2559905#msg2559905
Sessions aren't kept properly!

Quote from: Nao on June 07, 2010, 12:23:49 PM
BTW, your password is no longer active.
Yes it is!

:)

Quote from: Norv on June 07, 2010, 12:42:08 PM
My apologies for the delay, MultiformeIngegno.
Hey man, I always follow the development on mantis and you (and of course the other that are working on SMF) are doing an awesome job!!! Keep it up and compliments!!!!! ;)
RockCiclopedia (wiki - forum), Tutta la storia del rock, scritta da voi ...
Rimanere aggiornati sul mondo della musica grazie al nuovo feed "RockCiclopedia Music News"!

Nao 尚

Okay Lorenzo, I have plenty of both very good and quite bad news for ya...

- I reproduced a similar setup on my website, and managed to connect. So that's the good news.
- I don't know if the different is because it's not a totally similar setup (bad news), or because my own site fixes it (good news).

Now, my forum is in the root, so here's how I did it:
- I have a subdomain that redirects to /Themes/default/, both cookieless (http://static dot cyna dot fr) and with cookies (http://static dot noisen dot com) (I'm not putting direct links because I don't want Google to look into them. I'm a bit strange.)
- In /Themes/default/ssi_test.php, I put your code... Replacing the 'test_forum' path with '..' (i.e., "../../SSI.php"), so that it could access the proper one.
- Then I went to the cookieless version, tried to login... And I was simply redirected to the noisen.com site, without error messages, and without being logged in. This may be bad news: if I haven't got the error, maybe, maybe it's due to some weird setup on my site.
- I went to the cookie-enabled version (http://static dot noisen dot com/ssi_test.php, I trust you can type it), and tried to login. I was immediately redirected to noisen.com, *and* was logged in. Again, this may be bad news: shouldn't the login box redirect me to the original SSI page instead of the forum homepage...? The good news, though, is that I was also logged into the SSI page when I hit "back" and refreshed the SSI page.
- Then I simply clicked Logout from the SSI page, and was properly logged out from both the forum and SSI pages.

So... All in all, it's an interesting development I guess.

You may want to ask me, "how come it works on your site?"
I know it may very well be due to some reason I don't know at all, but all I can say is: because noisen.com has been running on multiple subdomains for several years now, and even though it doesn't use a single line of SSI.php code, I've be confronted MANY times with session errors due to the different subdomains.
I submitted some of them, some got fixed, etc, but all in all, I knew SMF needed to be reworked even more. So I did it on my side. This is probably the part of SMF that I hacked the most into, with many changes in variable names and such, but in the end, not only does it work, but it's been going steady for the last couple of years. I had a last bug that I fixed last year after someone complained about session problems with Firefox.

What I'd like others to do:
- Please go to that page and try logging into noisen.com (if you have an account, obviously.)
- Please confirm to me that the SSI login behavior is the same as what happens,
- Worship me, because I'm f'ing cool. Wonder at how a totally unrelated fix can sometimes help other problems,
- Discuss whether or not my fixes should be included into SMF 2.0.

*Obviously*, I have absolutely no problem sharing my code changes, and implementing them into the SVN. Let me just warn you that it's quite a large amount of code rewrites, but at least it would allow for PrettyURLs and similar URL rewriters to manage subdomains flawlessly, and would render SSI usable on subdomains as well. *And* it's been tested and re-tested for years.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Nao 尚

NB: ever since I posted my message, the ssi_test file wouldn't work anymore. That's just because I forgot to re-upload my mint copy after trying to remove a layer from it. Sorry about that.
I also re-tried the file after removing the .htaccess (which could have had an influence over it), and it worked the same. On the very first try, though, it didn't "register" my login attempt at the board index, I don't know why. But on the second and all subsequent attempts, it did.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

MultiformeIngegno

I've tried your test page and it works!! What does this mean? Are you able to fix SSI.php or it works because you are not using SSI.php (bad news, because means that ssi.php remains bugged)? What's the issue with the "default" sessions?

P.S.: Have you however reproduced this bug on a fresh installation? I've tried it 2 times with 2 fresh installations on 2 different hosts and I always reproduce this bug.. so it works for you due to your code changes (a good news, isn't it?).. :)
RockCiclopedia (wiki - forum), Tutta la storia del rock, scritta da voi ...
Rimanere aggiornati sul mondo della musica grazie al nuovo feed "RockCiclopedia Music News"!

Nao 尚

Quote from: MultiformeIngegno on June 08, 2010, 10:50:06 AM
I've tried your test page and it works!! What does this mean? Are you able to fix SSI.php
I guess I am?

Quoteor it works because you are not using SSI.php (bad news, because means that ssi.php remains bugged)? What's the issue with the "default" sessions?
I don't know.
What I know is that I've used the SSI code you asked me to use. I only changed the path to the SSI.php file.

QuoteP.S.: Have you however reproduced this bug on a fresh installation?
No. Please re-read my post. Noisen is a heavily modified forum. I've rewritten a lot of places to accept multiple subdomains in areas that PrettyURLs would usually fail to make work. (As a sidenote: I still use a custom version of PrettyURLs from 2 years ago, so it may not be compatible with my changes at all.)
I believe these changes are what helped.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Nao 尚

Been looking into my code and it's hard to find anything that could have an influence...
There are no changes related to login in SSI.php, script.js or suspicious files in the Sources folder.
Then I thought it could be because I didn't have the sha1.js script included in my page (I don't know why it's not in my index template... But it isn't. Probably forgot to put it in while updating my theme. Is this of any security-related importance? I'm leaving it in for now.)
It's not related to the form URL either -- we both "connect" to the board index, rather than the SSI page itself.
This may be eluding all of us for a while... But in the end we'll get it right I'm sure.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Arantor

Nao: I believe the sha1.js is of security implications; remember when the password is sent, assuming JS is enabled, the password is actually hashed before it's sent and sent into a different $_POST element (and the main password item is emptied)
No good deed goes unpunished
All helpful urges should be circumvented

Nao 尚

Quote from: Arantor on June 08, 2010, 12:02:23 PM
Nao: I believe the sha1.js is of security implications; remember when the password is sent, assuming JS is enabled, the password is actually hashed before it's sent and sent into a different $_POST element (and the main password item is emptied)
Yes, but what I was wondering is whether this security issue is of the utmost importance or not. Since, well, in that case people with JS disabled would be in trouble...
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Arantor

Not really, all it means then that it's just sent as-is rather than hashed; think of it as one less security feature.
No good deed goes unpunished
All helpful urges should be circumvented

MultiformeIngegno

The research shouldn't be that big: the problem doesn't affect RC2 so it's something added/changed in RC3, at 99% the way that smf handles sessions (at every refresh of my ssi page the session number changes!).
RockCiclopedia (wiki - forum), Tutta la storia del rock, scritta da voi ...
Rimanere aggiornati sul mondo della musica grazie al nuovo feed "RockCiclopedia Music News"!

Nao 尚

Lorenzo, I suspect that the change between RC2 and RC3 is that the session variable name was changed from "sesc" to a random hex string. (I don't know if the change happened between RC2 and RC3, but it's likely innit?)
Now, it would be horrible if I were to discover that the reason my version works is not because of that (and a workaround I found around it), but because I haven't implemented the RC3 fix into my code... Which is quite unlikely though, as I always do my best to sync everything between noisen and the SVN. Most of my changes are in Load.php, I haven't looked into that one yet.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Arantor

Nah, that change happened long before; that was in RC1 (as Orstio has noted, that was done around the time of 1.1.6)
No good deed goes unpunished
All helpful urges should be circumvented

MultiformeIngegno

RockCiclopedia (wiki - forum), Tutta la storia del rock, scritta da voi ...
Rimanere aggiornati sul mondo della musica grazie al nuovo feed "RockCiclopedia Music News"!

Arantor

Yup. Possibly one of the 45 vulnerabilities fixed.

I would be interested to know if the same thing is broken on 1.1.11 actually.
No good deed goes unpunished
All helpful urges should be circumvented

Nao 尚

I'd love to have that list of 45 vulnerabilities... Or, more interestingly, the list of changes they represent.

Really need to find a way to pinpoint how I 'fixed' it on my site!
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

MultiformeIngegno

RockCiclopedia (wiki - forum), Tutta la storia del rock, scritta da voi ...
Rimanere aggiornati sul mondo della musica grazie al nuovo feed "RockCiclopedia Music News"!

Arantor

No, they're not. They're on another site. Since it's an active list of vulnerabilities, I'm not sharing it on this forum. I have notified Nao of the link, though, and I believe the dev team is aware of it. In fact, they're due a visit from Marketing over breaching SMF's licence...
No good deed goes unpunished
All helpful urges should be circumvented

Nao 尚

Yeah, interesting breach... Although I don't know if at this point, it matters much at all. (No details needed.)
As for the security issues, I'm afraid I don't have enough time to look into them for now. FWIW, most of them are probably dummy. Right now I'd rather focus on my bug list in Mantis. I'm making progress on a few of them.
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Advertisement: