« RT Documentation Now Online | Main | RT 4.0.9 Released »

October 26, 2012

Security vulnerabilities in RT

We have determined a number of security vulnerabilities which affect both RT 3.8.x and RT 4.0.x. We are releasing RT versions 3.8.15 and 4.0.8, and RTFM version 2.4.5, to resolve these vulnerabilities, as well as patches which apply atop all released versions of 3.8 and 4.0.

The vulnerabilities addressed by 3.8.15, 4.0.8, and the patches include the following:

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.

RT 4.0.0 and above and RTFM 2.0.0 and above contain a vulnerability due to lack of proper rights checking, allowing any privileged user to create Articles in any class. We have been assigned CVE-2012-4731 for this vulnerability.

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.

If you are running 3.8.x and RTFM, you will need to install RTFM 2.4.5 to resolve CVE-2012-4731. Patches for all releases of 3.8.x and 4.0.x are available for download; The README within it contains instructions for applying the patches. Otherwise, we recommend upgrading to RT 4.0.8, which resolves the above vulnerabilities.

If you are using RT::Authen::ExternalAuth, you also need to upgrade it to version 0.12 for compatibility with the security fixes in RT 4.0.8, 3.8.15, and the patches.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Security vulnerabilities in RT:


Feed You can follow this conversation by subscribing to the comment feed for this post.

Is there list of features for upcoming 4.2 release and a guesstimate ETA?

As a rule, we don't promise release dates (even potential "estimates"). The best way to judge how close 4.2 is to a release is to watch rt-devel for announcements of release candidates.

No curated "what's new in 4.2" feature list exists right now, although we may publish some preview blog posts as we get closer. To get an idea, take a look at the branches merged into the master branch, as well as the outstanding branches whose name starts with 4.2/. You'll need to clone the git repo, as github doesn't show the full list of branches.

The comments to this entry are closed.