A new 3.8.15 upstream version of Request Tracker (RT) 3 has been released:
correcting the following security flaws (from ):
All versions of RT are vulnerable to an email header injection attack. Users with ModifySelf or AdminUser can cause RT to add arbitrary headers or content to outgoing mail. Depending on the scrips that are configured, this may be be leveraged for information leakage or phishing. We have been assigned CVE-2012-4730 for this vulnerability; we would like to thank Scott MacVicar for bringing this matter to our attention.
All versions of RT with cross-site-request forgery (CSRF) protection (RT 3.8.12 and above, RT 4.0.6 and above, and any instances running the security patches released 2012-05-22) contain a vulnerability which incorrectly allows though CSRF requests which toggle ticket bookmarks. We have been assigned CVE-2012-4732 for this vulnerability; we would like to thank Matthew Astley for bringing this to our attention.
Additionally, all versions of RT are vulnerable to a confused deputy attack on the user. While not strictly a CSRF attack, users who are not logged in who are tricked into following a malicious link may, after supplying their credentials, be subject to an attack which leverages their credentials to modify arbitrary state. While users who were logged in would have observed the CSRF protection page, users who were not logged in receive no such warning due to the intervening login process. RT has been extended to notify users of pending actions during the login process. We have been assigned CVE-2012-4734 for this vulnerability; we would like to thank Matthew Astley for bringing this to our attention.
RT 3.8.0 and above are susceptible to a number of vulnerabilities concerning improper signing or encryption of messages using GnuPG; if GnuPG is not enabled, none of the following affect you. We have been assigned CVE-2012-4735 for the following related vulnerabilities:
* When using GnuPG, RT now clarifies the concepts of signing for _integrity_ and signing for _authentication_, which are separate (and exclusive) concepts. Previously, enabling the "Sign by default" queue configuration began signing automatically-generated messages with the queue's key, in addition to defaulting emails sent from the web UI to being signed. This provides integrity, but causes emails signed with that key to no longer possess authenticity; no individual email is guaranteed to have come from an actor designated to act for that key, in the case of automatically-generated emails.
RT has now changed the "Sign by default" checkbox to merely provide a default in the web UI when composing messages; it no longer affects automatically-generated outgoing messages. Thus the "Sign by default" option helps to provide _authenticity_. A separate queue configuration option, "Sign all auto-generated mail" (defaulting to off) now controls the signing of automatically-generated emails, which (when used in combination with the previous option) helps provide _integrity_ of all outgoing messages.
Users who had previously checked "Sign by default" and who wish to maintain the previous effect of integrity but not authenticity will need to enable the new option as well.
We would like to thank Matthijs Melissen (University of Luxembourg) for bringing this matter to our attention.
* RT 3.8.0 and above contain a vulnerability which allows incoming emails to force all triggered outgoing mail to be signed and/or encrypted.
* RT 3.8.0 and above contain a vulnerability which allows incoming emails to incorrectly appear in the UI to have been encrypted when they had not been. This vulnerability only applies to encryption, not signing.
* RT 3.8.0 and above contain a vulnerability which allows any user who is capable of sending signed email in the UI to do so using any secret key stored in RT's keyring.
Additionally, RT 3.8.0 and above contain a vulnerability which allows a user to pass arbitrary arguments to the command-line GnuPG client, which could be leveraged to create arbitrary files on disk with the permissions of the webserver. This vulnerability only applies if GnuPG is enabled, and does _not_ allow for execution of programs other than the command-line GnuPG client. We have been assigned CVE-2012-4884 for this vulnerability.
Created rt3 tracking bugs for this issue
Affects: fedora-all [bug 870407]
Affects: epel-all [bug 870408]
Regarding the RT v3.6 based version in Fedora EPEL 5. From :
"Patches for all releases of 3.8.x and 4.0.x are available for download below. As RT 3.6.x has reached end of life, we will not be releasing patches for it; please contact sales at bestpractical.com if you need assistance with RT versions older than 3.8.0."
The CVE-2012-4735 identifier has been rejected in favour of: CVE-2012-6578, CVE-2012-6579, CVE-2012-6580, and CVE-2012-6581:
** REJECT **
DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2012-6578,
CVE-2012-6579, CVE-2012-6580, CVE-2012-6581. Reason: This candidate
is a duplicate of CVE-2012-6578, CVE-2012-6579, CVE-2012-6580, and
CVE-2012-6581. Notes: All CVE users should reference one or more of
CVE-2012-6578, CVE-2012-6579, CVE-2012-6580, and CVE-2012-6581
instead of this candidate. All references and descriptions in this
candidate have been removed to prevent accidental usage.
with CVE-2012-6578, CVE-2012-6579, CVE-2012-6580, and CVE-2012-6581 description being as follows:
Best Practical Solutions RT 3.8.x before 3.8.15 and 4.0.x before 4.0.8, when GnuPG is enabled with a "Sign by default" queue configuration, uses a queue's key for signing, which might allow remote attackers to spoof messages by leveraging the lack of authentication semantics.
Best Practical Solutions RT 3.8.x before 3.8.15 and 4.0.x before 4.0.8, when GnuPG is enabled, allows remote attackers to configure encryption or signing for certain outbound e-mail, and possibly cause a denial of service (loss of e-mail readability), via an e-mail message to a queue's address.
Best Practical Solutions RT 3.8.x before 3.8.15 and 4.0.x before 4.0.8, when GnuPG is enabled, does not ensure that the UI labels unencrypted messages as unencrypted, which might make it easier for remote attackers to spoof details of a message's origin or interfere with encryption-policy auditing via an e-mail message to a queue's address.
Best Practical Solutions RT 3.8.x before 3.8.15 and 4.0.x before 4.0.8, when GnuPG is enabled, allows remote attackers to bypass intended restrictions on reading keys in the product's keyring, and trigger outbound e-mail messages signed by an arbitrary stored secret key, by leveraging a UI e-mail signing privilege.
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.