It was found that Request Tracker, a ticket tracking and management system, stored user passwords in its database by using insufficiently secure hashing algorithm. A local attacker, able to gain read access to the RT's database could use this flaw to conduct brute force password guessing attacks, potentially leading to disclosure of users' passwords. References: [1] http://lists.bestpractical.com/pipermail/rt-announce/2011-January/000185.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610850 [3] http://www.debian.org/security/2011/dsa-2150 RT Development Snapshots archive URL: [4] http://download.bestpractical.com/pub/rt/devel/
This issue affects the versions of the rt3 package, as shipped with Fedora release of 13 and 14. -- This issue affects the versions of the rt3 package, as present within EPEL-5 and EPEL-6 repositories. Please schedule an upgrade to latest release candidates [1], [4].
Created rt3 tracking bugs for this issue Affects: fedora-all [bug 672257]
This has been fixed in upstream version 3.8.9: http://lists.bestpractical.com/pipermail/rt-announce/2011-February/000186.html
Created rt3 tracking bugs for this issue Affects: fedora-all [bug 672257] Affects: epel-6 [bug 680217]
(In reply to comment #3) > This has been fixed in upstream version 3.8.9: Correct me if I'm wrong, but aren't 3.8.9 (mysql-) databases incompatible to 3.8.8's (Fedora 14) rsp. 3.8.7 (Fedora 13)? Fedora 15 and rawhide carry 3.8.9. Or let me ask differently: Is it possible to upgrade from 3.8.7 rsp. 3.8.8 to 3.8.9 without manually reformating the databases? As I read rt-3.8.9/UPGRADING, * upgrading 3.8.8->3.8.9 without reformating the databases is possible, while * upgrading 3.8.7->3.8.9 without reformating the databases is not possible (Due to changes between 3.8.7 and 3.8.8).
I don't use rt3 so I'm honestly not sure. It looks like there are some manual steps that need to be taken for both upgrades, but I'm not sure about "reformatting the database" (I'm also unsure what that means). Looking at the UPGRADING-3.8 file (https://github.com/bestpractical/rt/blob/master/docs/UPGRADING-3.8) it does seem that there needs to be some changes done to fix the vulnerable password hashes. I suspect you need to log into the database, so I'm not sure if you can run the password fixing script in %post automatically; you may need to alert users that the changes to the db need to be done manually (although I don't know if it's _mandatory_ in order to run; it's possible the new version will run with the old hashes but simply will be as insecure as the old versions until the user upgrades -- that would require some testing I suspect or asking upstream). I would think that the code changes are to make use of the new hashes, not necessarily reject the old ones (but again, I don't use rt3 so have no idea).
rt3-3.6.11-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.