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

[Orstio]

http://www.simplemachines.org/community/index.php?topic=373342.msg2562443#msg2562443

I don't see a way to retrieve or pass a value to $context['session_var'].  This essentially breaks all interactions in regard to integration (no login, no logout, no posting, no voting in polls, etc. through integration.)  This renders SSI.php pretty much useless for anything other than non-interactive display (recent topics, recent posts, etc.)

[MultiformeIngegno]

[See this post for the procedure to reproduce it!]

As explained in the topic linked above, the behavior is the following:
In SSI pages located on different subdomain from the forum one, if you try to login with your right username and password from the ssi page login box, you are always redirected to the forum login with a "password wrong" error. Then after you have logged in from the forum, if you come back to the ssi page and you try to logout, you get a "session verification failed" error. I've noticed also that if you refresh the page the session number included in the logout link changes!!

Is there a temporary workaround? Maybe a code "downgrade" to RC2?
Please help me, my whole site is based on ssi.php!!

Thanks in advance,
Lorenzo

[Orstio]

If I were you, I wouldn't hold my breath.

The bug is big enough that there is no quick fix.  You're not going to get a small patch code to make it work.

So, the best that's going to happen is it will be fixed for 2.0 RC4.  The worst case is it's never fixed.

[MultiformeIngegno]

If I were you, I wouldn't hold my breath.

The bug is big enough that there is no quick fix.  You're not going to get a small patch code to make it work.

So, the best that's going to happen is it will be fixed for 2.0 RC4.  The worst case is it's never fixed.

There's no way to replace the interested code with the RC2 one (that worked properly)?

Anyway.... this is a MAJOR BUG, that needs to be absolutely fixed for RC4!! I can't even see it on the bug tracker!

[Orstio]

Most of the bugs posted here don't make it onto the bug tracker.  Even the ones that do don't necessarily get fixed.

Keep in mind there are only three volunteer developers.  They can't possibly keep up with it all in only their spare time.

[MultiformeIngegno]

...and about the possibility to replace the piece of code with the RC2 one (that worked properly)?

[Orstio]

It's not just one piece of code that needs changing.  As I said, it's not just a quick patch, or I would have posted one for you.  It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.

[Norv]

Tracked as http://dev.simplemachines.org/mantis/view.php?id=4244, in order to be more easily found and considered by the devs. Also reported it directly to the people responsible with it.

Thank you both for the report and Orstio for taking the time to look into it. I will most likely not be able myself to investigate this properly soon, for lack of time and tools at my disposal for the moment, but hopefully it will be taken into consideration as soon as possible.

[Arantor]

It's not just one piece of code that needs changing.  As I said, it's not just a quick patch, or I would have posted one for you.  It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.

Well, I think the idea is that it makes it harder to grab the session and reuse it since you're no longer user sesc=[session id] in the HTTP request, you also need the session variable too.

Though if you can grab one... presumably you can grab the other too. It just makes it slightly harder to notice if you're just randomly snooping.

[Orstio]

It's not just one piece of code that needs changing.  As I said, it's not just a quick patch, or I would have posted one for you.  It's a number of patches in a number of files, and considering this obfuscation was done with some weird sense of better security, it is also unlikely to be reverted.

Well, I think the idea is that it makes it harder to grab the session and reuse it since you're no longer user sesc=[session id] in the HTTP request, you also need the session variable too.

Though if you can grab one... presumably you can grab the other too. It just makes it slightly harder to notice if you're just randomly snooping.

It's the same logic that makes people want to remove their copyright for "security reasons".  Script-kiddies are called script-kiddies because they run automated scripts.  Nobody is doing any random snooping, they are doing systematic runs of exploit checks.  If $sesc could have been exploited, then the exploit should have been fixed, not obfuscated.  What that says to me is that the underlying security issue is still there, it's just hidden better.

And, I agree with you -- it is harder to grab the session and reuse it.  In fact, it's pretty much impossible, even from SSI.php.  Thus, this bug report.  See, if a security fix breaks functionality, it's what's called "throwing the baby out with the bath-water".  It's like welding the doors shut on your car so nobody can get in to steal it.  Unfortunately, it also means you can't get in to drive it either.

There is no point in the SSI functionality if it isn't going to work.  It's bad enough that the SSI login/logout redirect bug has been around since the session fixation security fix (1.1.6?) and never fixed.  Now there's an even bigger SSI.php file with even more functions, and half of them rendered useless by obfuscating a variable name.

[MultiformeIngegno]

There is no point in the SSI functionality if it isn't going to work.  It's bad enough that the SSI login/logout redirect bug has been around since the session fixation security fix (1.1.6?) and never fixed.  Now there's an even bigger SSI.php file with even more functions, and half of them rendered useless by obfuscating a variable name.

You're right... SSI is the strong point of SMF!!

P.S.: Thanks Norv!

[MultiformeIngegno]

OK, I'm able to reproduce clearly this issue. Here's the procedure:

You have a freshly installed SMF 2.0 RC3 in a /test_forum folder. Now create a subdomain, testforum.yourdomain.com (that of course has test_forum as main dir). Now change the forum url to use the subdomain. OK. Create a new folder in your server (out of the forum one), called /test_ssi. Now put there your ssi file, called myssifile.php:

Code Select Expand


<?php
// Layers to be utilized
$ssi_layers = array('html', 'body');

//This is the SSI.php file in the Board dir.
require('../test_forum/SSI.php');
?>

My test file!

<?php
ssi_shutdown();
?>


Now create another subdomain so you have testssi.yourdomain.com (with of course /test_ssi as main directory). Now clear your cookies/cache/everything and go to -> testssi.yourdomain.com/myssifile.php. You should see your ssi-based file with (of course) the login box. Now try to login, you should get the "password wrong" error and all the behaviors that we've talked about (sessions number that changes at every refresh, etc...)!

ALL THIS HAPPENS WITH THE OPTIONS "Use subdomain independent cookies" ON and "Enable local storage of cookies" OFF!

If you're on the same subdomain or without subdomains, you don't have these issues (or at least I can't reproduce 'em!).

[MultiformeIngegno]

I'd like to bump this and also report another behavior I think related to this: in one of my ssi-based pages (on a different subdomain from the forum one) I use the ssi_recentTopics function, this is my code:

Code Select Expand


<?php
global $context, $settings, $scripturl, $txt;
global $user_info, $modSettings, $smcFunc, $posts;
global $color_profile;
$array = ssi_recentTopics(10, null, null, 'array');

echo '<div id="recentpost">';

$odd = false;
foreach ($array as $post)
{
  echo '<div class="recentpost ', ($odd ? 'odd' : 'even'), '">
<span class="topicname" style="font-size: 85%"><strong><a href="', $post['href'], '">', $post['subject'], '</a></strong></span>

', !$post['is_new'] ? '' : '<a href="' . $scripturl . '?topic=' . $post['topic'] . '.msg' . $post['new_from'] . ';topicseen#new" rel="nofollow"><img src="' . $settings['lang_images_url'] . '/new.gif" alt="' . $txt['new'] . '" border="0" /></a>', '

<br /><small>Posted by <span class="author">', $post['poster']['link'], '</span><br /><span class="date">', $post['time'], '</span><br /><em>(Views: ', $post['views'], ' | Replies: ', $post['replies'], ')</em></small><br /><br />
</div>';

  $odd = !$odd;
}
echo '
</div>';
?>


Now, sometimes (I really can't figure why this happens only sometimes) instead of going to the topic, I'm redirected to the board index!

Here's the link of one of the topic links when this happens:
http://forum.rockciclopedia.com/index.php?PHPSESSID=4e9ca3e505fdaf32d747fb9831b6d9b7&/topic,1352.msg22299/topicseen.html?PHPSESSID=4e9ca3e505fdaf32d747fb9831b6d9b7#new
(I don't have any pretty url/simplesef/topic-related mod or other strange ones, I only have seo-friendly urls enabled. I've also tried to disable tht option but this still happens!)

So, this finally seems related to the (huge) issue with sessions!

[Orstio]

What do the URLs look like if you turn off SEO Friendly URLs in SMF?

[MultiformeIngegno]

Unfortunately it's not easy to reproduce this latest behavior (I really can't understand when happens)... anyway I didn't understand yet if you managed to reproduce the main (and most important) issue..:

OK, I'm able to reproduce clearly this issue. Here's the procedure:

You have a freshly installed SMF 2.0 RC3 in a /test_forum folder. Now create a subdomain, testforum.yourdomain.com (that of course has test_forum as main dir). Now change the forum url to use the subdomain. OK. Create a new folder in your server (out of the forum one), called /test_ssi. Now put there your ssi file, called myssifile.php:

Code Select Expand


<?php
// Layers to be utilized
$ssi_layers = array('html', 'body');

//This is the SSI.php file in the Board dir.
require('../test_forum/SSI.php');
?>

My test file!

<?php
ssi_shutdown();
?>


Now create another subdomain so you have testssi.yourdomain.com (with of course /test_ssi as main directory). Now clear your cookies/cache/everything and go to -> testssi.yourdomain.com/myssifile.php. You should see your ssi-based file with (of course) the login box. Now try to login, you should get the "password wrong" error and all the behaviors that we've talked about (sessions number that changes at every refresh, etc...)!

ALL THIS HAPPENS WITH THE OPTIONS "Use subdomain independent cookies" ON and "Enable local storage of cookies" OFF!

If you're on the same subdomain or without subdomains, you don't have these issues (or at least I can't reproduce 'em!).

I managed to reproduce this in 2 different hosting and 2 different rc3 (clean) installations... You only need to install the forum in a subdomain and then create a page that calls ssi.php from a different subdomain!

[MultiformeIngegno]

Sorry to bump this but to help you I've created a test board to reproduce this, you can find it here:

FORUM: http://testforum.rockciclopedia.com [no more active, bug solved!]
SSI-PAGE: http://testextra.rockciclopedia.com [no more active, bug solved!]

I've created also a test-user.

To reproduce this behavior go to the SSI-PAGE, then insert this data in the header login box: "demo" & "password"
You'll receive a "password wrong" error, then try to login again always with demo & password (you're now in the forum) and it will work. Then try to logout from the ssi-page, it won't work. Instead it will work if you're in the forum.

Let me know if you need more info!

[MultiformeIngegno]

A feedback!

M,   i noticed when clicking on any link in "Music News", it takes me to the forum rather than the topic.

[Norv]

I will be looking into this as soon as possible, MultiformeIngegno. Really sorry, I didn't have much time lately, but that changes every once in the while...
I think there's enough information here to understand what's going on and be able to replicate afaics. Thank you, I'm sure all this work and feedback will prove truly useful.

[MultiformeIngegno]

Oh, didn't see your reply!
Thanks Norv!!

[MultiformeIngegno]

Noooooorv.....?