Re: [SM-USERS] Still problems with 1.4.19 and "you must be logged in" error

[<dw...@do...>]

Hello

We are still having big problems with cookies under testing, before we
upgrade to 1.4.19.

These problems are stopping us from upgrading from 1.4.17 to 1.4.19
because with 20.000+ user of squirrelmail in our system, having to
delete all squirrelmail cookie information from their browser will not
be a practical solution (not to mention the telefon queue we would get
in the support senter when squirrelmail stops working for all of them at
the same time)

The problem is the one explained in:

[SM-USERS] upgrade to 1.4.18 gives "you must be logged in" error
[SM-USERS] 1.4.18 bug with src/redirect.php on php4.3.3

Description of the problem:

After upgrading to 1.4.19, the only page an user will see after logging
in will be the default page with the left/right frame and folders/INBOX
information. Any click after this point will show a "you must be logged
in" error.

The only way of getting rid of this problem is deleting all cookie
information from squirrelmail in your browser or reverting to 1.4.17.

Deleting this code in src/redirect.php:

--------------------------------------------------------------------
if (function_exists('session_regenerate_id')) {

    session_regenerate_id();

    // re-send session cookie so we get the right parameters on it
    // (such as HTTPOnly, if necessary - PHP doesn't do this itself

    sqsetcookie(session_name(),session_id(),false,$base_uri);
}
--------------------------------------------------------------------

Or applying this patch to 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));
--------------------------------------------------------------------

Do not help and the problem is still there after these changes.

I think that the problem is not in src/redirect.php but in
function/global.php. This new code in 1.4.19 looks like a candidate for
being the origin of this problem, don't you think?:

--------------------------------------------------------------------
if (isset($_COOKIE[session_name()])) {
        sqsetcookie(session_name(), $_COOKIE[session_name()], 1,
$base_uri);

        /*
         * Make sure to kill /src and /src/ cookies, just in case there are
         * some left-over or malicious ones set in user's browser.
         * NB: Note that an attacker could try to plant a cookie for one
         *     of the /plugins/* directories.  Such cookies can block
         *     access to certain plugin pages, but they do not influence
         *     or fixate the $base_uri cookie, so we don't worry about
         *     trying to delete all of them here.
         */
        sqsetcookie(session_name(), $_COOKIE[session_name()], 1,
$base_uri . 'src');
        sqsetcookie(session_name(), $_COOKIE[session_name()], 1,
$base_uri . 'src/');
    }

    if (isset($_COOKIE['key'])) sqsetcookie('key', 'SQMTRASH', 1,
$base_uri);

    /* Make sure new session id is generated on subsequent
session_start() */
    unset($_COOKIE[session_name()]);
    unset($_GET[session_name()]);
    unset($_POST[session_name()]);
--------------------------------------------------------------------

Some tecnical information about our system:

- RHELS 5.3, Apache/2.2.11, PHP.5.2.8
- All traffic between the browser and apache uses SSL (port 443).
- Session data and userpref/addressbook are saved in a PostgreSQL database.


Do you need any more information?
How can we help to fix this problem?

regards
--
 Rafael Martinez, <r.m...@us...>
 Center for Information Technology Services
 University of Oslo, Norway

We are experiencing the same exact type problems as mentioned above by
Rafael and are also running squirrelmail 1.4.19 on RHEL 5.3 with Apache
2.2.11 and PHP 5.2.5. I have tried commenting the whole IF statement around
line 82 in src/redirect.php and that did not work for us. I am using IE 7
to test.

What I am seeing is intermittent and varies as such:
1.  Sometimes when browsing to src/login.php I am redirected to the login
error page instead.
2.  When browsing to src/login.php and not redirected to the login page and
successfully log in, either both frames or one of the frames will be blank
while the other correctly displays the web content.
3. When browsing to src/login.php and not redirected to the login page and
successfully login, either both frames or one of the frames will display
webpage cannot be displayed while the other correctly displays the web
content.
4. Clicking on IE's refresh sometimes successfully refreshes the faulted
frame and other times takes you to the login error page.
5. After logging in with both frames working and just leaving the browser
sitting there with Inbox messages displayed, the left pane either goes
blank or displays webpage cannot be displayed. I think it must be occurring
during an auto refresh of the folders pane (as set in the folder options) .

When I  simply reconfigure httpd.conf to point to webmail-1.4.17 vice
webmail-1.4.19 and restart the httpd service all of the above problems go
away.

I have not seen a response back to Rafael's email above yet and was
wondering what the status of this is and if there is something that can be
done to correct this. I am anxious to go back to 1.4.19 because of all of
the security fixes contained in 1.4.18 including the very important fix
regarding remote execution of server side code.

r/Derek Wnek