|Summary:||CVE-2009-0030 squirrelmail: session management flaw|
|Product:||[Other] Security Response||Reporter:||Tomas Hoger <thoger>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||advax, bressers, dowdle, kreilly, mhlavink, mjc, security-response-team, syeghiay|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-02-26 09:17:49 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||480224, 480490, 480491, 480492, 480493, 833980|
Description Tomas Hoger 2009-01-17 17:38:25 UTC
It was discovered that a backport of the patch for CVE-2008-3663 included in SquirrelMail packages as shipped in Red Hat Enterprise Linux 3, 4, and 5 contained a bug, that could result in different users being assigned insecure and identical session identifier. Such session identifiers were assigned if user logged out of SquirrelMail and logged in again without closing web browser. This could result in sessions of the multiple users to "merge". Certain data from one user's session could have been displayed to other user (such as folder structure, address book and options, but not individual mails), or result in the overwrite of the preferences data with other user's settings. Further details can be found in the bug #480224.
Comment 3 Josh Bressers 2009-01-19 20:57:01 UTC
Comment 4 advax 2009-01-20 21:14:07 UTC
We have seen the problems reported in #480224, and have rolled back from to 1.4.8-4.0.1.el4 to 1.4.8-5.el4_7.2 on EL4.5 to resolve them. We have had user preferences become corrupted causing mail to be sent apparently from a different user, or duplicated "from" a second user. When investigating I checked my cookies in Firefox which appeared to have "reasonable" values, deleted them, and logged in again to Squirrelmail. I noticed that I would be randomly logged out. Also on some occasions the list of subscribed folders in the left panel included folders belonging to another user, but if I clicked on them I got a "no such folder" error as they do not exist in my account.
Comment 5 Tomas Hoger 2009-01-21 07:36:30 UTC
Version 1.4.8-5.el4_7.2 is known to be affected by issues mentioned in the bug #480224. The update has been released to address them. If you are still seeing some issue with latest packages, please file a bug against squirrelmail component, with detailed steps to reproduce.
Comment 6 Scott Dowdle 2009-01-27 16:11:46 UTC
I'm running squirrelmail-1.4.8-5.el4_7.3 and I still have the issue. I have had two users report that email they are sending is using the account information from another user. I have logged in as them and verified that indeed all of the account settings information displayed is that of another user. I'm wondering if this is a result of corruption or data alteration created by the previous version... affecting the current version. In any event I have the latest version and a few users seem to have the problem. I don't know how wide spread the issue is (it hasn't affected my account) but I have had two users report it... and as I said, I verified it. Not sure where to do from here? Should I wait for an update (is there going to be one)? Should I rollback two versions (where there is a security issue)? In the meantime, I'm just disabling the webmail system.
Comment 7 Tomas Hoger 2009-01-27 17:42:24 UTC
As noted in bug #480224, corruption of the user preferences files was one of the most severe symptoms of this flaw, causing one user's preferences to be written to preferences files of other user (you should be able to manually verify by inspecting individual files in /var/lib/squirrelmail/prefs/). As was noted in the errata text, all users that have used affected version of squirrelmail (1.4.8-5.el4_7.2 on RHEL4) should review (and correct if needed) their preferences. Alternatively, restore from backup can be used to revert all users preferences to known good state. Updated packages make sure to immediately discard all bogus session identifier to avoid further corruptions, but can not undo changes that happened while broken packages were used.
Comment 8 Scott Dowdle 2009-01-27 17:58:32 UTC
Tomas, Thanks for responding to my recent addition to this bug report and bringing to my attention details I did not notice that were there. I will follow those instructions and report any additional problems if I encounter them although I don't anticipate having them.