[SEC][ANN] Rails 3.2.12, 3.1.11, and 2.3.17 have been released!

318 views
Skip to first unread message

Aaron Patterson

unread,
Feb 11, 2013, 1:30:51 PM2/11/13
to rubyonra...@googlegroups.com, rubyonra...@googlegroups.com, ruby...@ruby-lang.org
Hi everybody.

I'd like to announce that Rails 3.2.12, 3.1.11, and 2.3.17 have been released.

3.2.12 and 3.1.11 contain one security fix, and 2.3.17 contains two security fixes. It is recommended that you update immediately.

You can read about the security fixes by following these links:

* [CVE-2013-0276](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/AFBKNY7VSH8)
* [CVE-2013-0277](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/KtmwSbEpzrU)

Please note that today a new JSON gem was released, and it also contains an important security fix. You should update the JSON gem as soon as possible. You can read about the security issue in the JSON gem here:

* [CVE-2013-0269](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/4_YvCpLzL58)

In order to ease upgrading, the only major changes in each gem is the security fix. To see the detailed changes for each version, follow the links below:

* [Changes in 3.2.12](https://github.com/rails/rails/compare/v3.2.11...v3.2.12)
* [Changes in 3.1.11](https://github.com/rails/rails/compare/v3.1.10...v3.1.11)
* [Changes in 2.3.17](https://github.com/rails/rails/compare/v2.3.16...v2.3.17)

Thanks to the people who responsibly reported these security issues.

Please note that per our [maintenance policy](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/G4TTUDDYbNA) there will be no 3.0.x version released.

Here are the SHA-1 checksums for each gem:

## Rails 3.2.12

```
[aaron@higgins dist]$ shasum *3.2.*
5627c6d044cc52876128459d960f8805006b5f97 actionmailer-3.2.12.gem
336f76c045b6bcbd204831897131182cff82ddf8 actionpack-3.2.12.gem
89bec5d68861ad5d79ca776ef5d6df7c1cfc2b11 activemodel-3.2.12.gem
7d4327c54900f45c60947a63350e865843e193ef activerecord-3.2.12.gem
4b8ed4190f98a85b800ee7893bae5afd1bee0874 activeresource-3.2.12.gem
c9e44eed288140f556e6543b93fc45f8dd57a415 activesupport-3.2.12.gem
24b3b4633d7f131e61e50decc3aa11590941c6e2 rails-3.2.12.gem
a84262f1968e83141d290c034b20a28d38886d10 railties-3.2.12.gem
```

## Rails 3.1.11

```
[aaron@higgins dist]$ shasum *3.1.*
d80816e69614c1f0d96cb7d0f4a38bfdc8d84ff5 actionmailer-3.1.11.gem
f65cea0682b6051869d4125f7b441a7c6f59fcbe actionpack-3.1.11.gem
549ec2b67d4332b38cef1620b23e00e50e0774e6 activemodel-3.1.11.gem
3d342764b7ba3bae05190f15bcb35d401cd8121e activerecord-3.1.11.gem
19bd70bad6c4e4a555127a7738e71ac4829e6f61 activeresource-3.1.11.gem
7267b2f87bea5bd285f5d1bfe49bb2ba19df7c94 activesupport-3.1.11.gem
ca57e1243451385689343dbe2bb42e23058284df rails-3.1.11.gem
48cc801bdb7c31c4b6939235a60ef3e5008f5dbb railties-3.1.11.gem
```

## Rails 2.3.17

```
[aaron@higgins dist]$ shasum *2.3.*
5df1fe13db46ac10dec8bb607ef515881dcf09c5 actionmailer-2.3.17.gem
d1165517a185ae73ca8a4ac89549e695a23fedfa actionpack-2.3.17.gem
b24ff71e46b798d7c38504531cb7622955d9a20c activerecord-2.3.17.gem
9cc2a7bd60a959dcba099425954a1b9c53235ce5 activeresource-2.3.17.gem
4ccc935fdc4d7ede78a1c376453ecb502e48b7ed activesupport-2.3.17.gem
9613a97cb726f00de59ad6d0f901f7434f9c4733 rails-2.3.17.gem
```

<3<3<3

--
Aaron Patterson
http://tenderlovemaking.com/

Prem Sichanugrist

unread,
Feb 11, 2013, 9:10:32 PM2/11/13
to rubyonra...@googlegroups.com, rubyonra...@googlegroups.com, ruby...@ruby-lang.org, tende...@ruby-lang.org
Yep, it got in. I think @tenderlove forgot to update the CHANGELOG. https://github.com/rails/rails/compare/v3.2.11...v3.2.12

- Prem

On Monday, February 11, 2013 at 4:19 PM, Justin Hart wrote:

Were the ActiveRecord changes included in the GitHub diff intended to be released?  The Changelog says 'unreleased'.  It looks like its in reference to a note on the Security list: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/ZOdH5GH5jCU

I support the changes, just wondering if it was unintended since it wasn't mentioned in the OP.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

James Harton

unread,
Feb 11, 2013, 9:28:21 PM2/11/13
to rubyonra...@googlegroups.com
This[1] caused a bunch of our specs to fail (on 3.1.11), and due to the fact that they're not immediately related to the critical security fixes we're trying to deploy today we decided to revert them on our fork instead. Forgive me if I'm wrong, but it would seem unwise to me to include unrelated behaviour changes in a patch that is supposed to contain only one security fix?

Michael Koziarski

unread,
Feb 11, 2013, 9:45:01 PM2/11/13
to rubyonra...@googlegroups.com

On Tuesday, 12 February 2013 at 3:28 PM, James Harton wrote:

This[1] caused a bunch of our specs to fail (on 3.1.11), and due to the fact that they're not immediately related to the critical security fixes we're trying to deploy today we decided to revert them on our fork instead. Forgive me if I'm wrong, but it would seem unwise to me to include unrelated behaviour changes in a patch that is supposed to contain only one security fix?

It was intentionally included, if there's breakage (and it seems there is) we should fix that and release updates that fix the regressions *without* removing the important security fix.

Will Bryant

unread,
Feb 11, 2013, 9:49:40 PM2/11/13
to rubyonra...@googlegroups.com

On 12/02/2013, at 15:45 , Michael Koziarski <mic...@koziarski.com> wrote:

> It was intentionally included, if there's breakage (and it seems there is) we should fix that and release updates that fix the regressions *without* removing the important security fix.

I'm surprised that it was included after the earlier security advisory about this issue said only Rails 4 would get chances to mitigate it. Did the risk assessment get worse or is it just doing whatever we can to improve the situation?

I've posted my 2c on the corresponding pull request, https://github.com/rails/rails/pull/9207. Doesn't feel like a safe approach to me, and it's broken basic join conditions when there's table aliasing.

Michael Koziarski

unread,
Feb 11, 2013, 9:54:11 PM2/11/13
to rubyonra...@googlegroups.com




I'm surprised that it was included after the earlier security advisory about this issue said only Rails 4 would get chances to mitigate it. Did the risk assessment get worse or is it just doing whatever we can to improve the situation?


I'm sorry if I was unclear in the advisory, it was always the intention:

Future releases of Rails will contain changes to mitigate the risk of 
this class of vulnerability, however as long as this feature is still 
supported this risk will remain. 

This release was in the future, however I can see how you might have taken that to only mean 4.0 

 
I've posted my 2c on the corresponding pull request, https://github.com/rails/rails/pull/9207. Doesn't feel like a safe approach to me, and it's broken basic join conditions when there's table aliasing.
Yeah, in the event there's no *pre queried* tables, we should just revert to the 'raw' quoting we do now.  This should be something where we quote safely wherever we can, but revert to going 'bareback' when we don't know.


-- 
Cheers,

Koz

James Harton

unread,
Feb 11, 2013, 9:57:06 PM2/11/13
to rubyonra...@googlegroups.com
As I said, we reverted it for our fork for reasons of expediency (since we've already disabled the vulnerabilities it's trying to mitigate). I am not suggesting that it should be reverted for everyone, I'd just like to see it fixed.

-- 
James Harton
@jamesotron
+64226803869

Reply all
Reply to author
Forward
0 new messages