Re: [SM-USERS] 1.4.18 bug with src/redirect.php on php4.3.3

[Paul L. <pa...@sq...>]

On Fri, May 15, 2009 at 5:33 PM, Paul Lesniewski <pa...@sq...> wrote:
> Andreas,
>
>> ok, here we are with the cookies.
>
> Thanks for helping us!

In addition to the things in my last email....

Can you confirm whether or not your sessions are stored in files (and
not database, for example)?

Also, are you using SSL (https) to connect?

Can you try adding two lines immediately after the regenerate?

Index: src/redirect.php
===================================================================
--- src/redirect.php    (revision 13680)
+++ src/redirect.php    (working copy)
@@ -80,6 +80,8 @@
      */
     if (function_exists('session_regenerate_id')) {
         session_regenerate_id();
+        if (!headers_sent())
+           sqsetcookie(session_name(),session_id(),false,$base_uri);
     }

     $onetimepad = OneTimePadCreate(strlen($secretkey));


>> just login page:
>> after login page load:
>>
>> SQMSESSID
>> 600f0903f14941db0d8d7a8a6b81b1ff
>>
>> before regenerate:
>>
>> SQMSESSID
>> 600f0903f14941db0d8d7a8a6b81b1ff
>>
>> i.e., before regenerate call, sessionid keeps the same.
>
> As expected.  Surely this is all normal.
>
>> second try:
>> (exit immed. after regernate)
>>
>> after login page load:
>>
>> SQMSESSID
>> 080de59be5b358b9b0993b95cf3870f8
>>
>> after regenerate:
>>
>> SQMSESSID
>> 7098cd4e23d8b90e0ad4d5dfdf2c186a
>> squirrelmail_language
>> de_DE
>>
>> so, the regenerate alters sessionid despite of an valid login!
>
> This is as expected, too.  All is well so far.  The one thing to check
> here, though, is if the session data moved to the correct place at the
> same time.  Can you try this again and look at your session files to
> see if the content went into the correct one?  The session files are
> in the location specified by session_save_path in php.ini....
> typically something like /var/lib/php/session
>
>> Third try
>> (exit imm. after sessio_write_close)
>>
>> after login page load:
>>
>> SQMSESSID
>> 6a76ecbe957184ad7dc8563d0e950da4
>>
>> after session_write_close():
>> SQMSESSID
>> 0078fc5c6ed3a6faa756a85efed62358
>> squirrelmail_language
>> de_DE
>> key
>> KouVaayIPl81TQ%3D%3D
>>
>> (that's just to verify the second try).
>>
>> Hope this gets you further.
>
> Well, it all looks correct here - no explanation why the session would
> fail.  Perhaps the session data not moving to the right file?  If it
> is, the next step would be to put an exit statement near the beginning
> of /src/webmail.php and see both what the browser's cookie is at that
> time and what is in the corresponding session data file.  If you do
> this at the top of webmail.php, keep in mind, the PHP session won't be
> started at that point (that's OK).
>
> If everything looks good there, check that this page request is the
> one that is failing in the first place.  Go to include/validate.php,
> add this code at line 56, before the is_logged_in() call:
>
> if (stristr($_SERVER['PHP_SELF'], '/src/webmail.php')) {
>   sm_print_r($_COOKIE, $_SESSION);
>   exit;
> }
>
> If you find a setting for "is_logged_in" therein, move this code to
> after the is_logged_in() call and make sure it appears again - in
> which case this is not where the process is failing (which would be
> even more perplexing).
>
> If the above does prove to be where the session is failing, does that
> session output show anything at all?  Is it just empty? How does the
> cookie output compare to what's on your browser side?  What about the
> ID?  The session data file?  We might need to check in
> sqsession_start() in functions/global.php when webmail.php is loading
> if nothing here shows the problem.
>
> Also, do you have session.auto_start turned off?  You can show the
> output of src/configtest.php too...
>
>> I will simply comment out the session_regenerate_id() call, as long as I
>> use PHP 4
>>
>> squirrelmail_language
>> de_DE
>> Paul Lesniewski schrieb:
>>> On Thu, May 14, 2009 at 5:44 AM, Andreas Vogt <a_...@ga...> wrote:
>>>>
>>>> (SM 1.4.18, PHP 4.3.3)
>>>>
>>>> Hi,
>>>>
>>>> after updating to 1.4.18
>>>> all users are immediatley logged out afters login.
>>>> SM just asks the IMAP server for INBOX, then the SM logs out.
>>>>
>>>> I could break this issue down to
>>>> line 82 in src/redirect.php
>>>>  session_regenerate_id();
>>>>
>>>> As stated in new redirect.php:
>>>> * NB: session_regenerate_id() was added in PHP 4.3.2 (and new session
>>>>
>>>> *     cookie is only sent out in this call as of PHP 4.3.3), but PHP 4
>>>>
>>>> *     is not vulnerable to session fixation problems in SquirrelMail
>>>>
>>>> Obviuosly, PHP 4.3.3. got some problems with
>>>>   session_regenerate_id();
>>>
>>> Ugh, yes indeed it looks like it.  Can you take snapshots of the
>>> SquirrelMail cookies in your browser for each step? --
>>>
>>>   - after login page loads
>>>   - just before the regenerate() call (put an exit; call before it)
>>>   - just after the regenerate() call (put an exit; call after it)
>>>   - after the session_write_close() call but before the
>>> header('Location') redirect
>>>     (put an exit; call between the two) - should be around line 181
>>>
>>> It might also be helpful to see the contents of $_COOKIE under each of
>>> those steps.
>>>
>>>> I tried to disable line 82. After this, everything works great, but I
>>>> don't know, what security problems I will get now (beside of having PHP
>>>> 4.3.3 ;) )
>>>
>>> Probably none - it seems to be mostly a PHP 5 issue.
>>>
>>>> best regards and thank you for your great job!
>>>

-- 
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donate_paul_lesniewski.php