From the upstream advisory:
There is a vulnerability in the escaping code for the form helpers in
Ruby on Rails. Attackers who can inject deliberately malformed unicode
strings into the form helpers can defeat the escaping checks and inject
Versions Affected: 2.0.0 and *all* subsequent versions.
Not affected: Applications running on ruby 1.9
Fixed Versions: 2.3.4, 2.2.3
Candidate CVE: CVE-2009-3009
Due to the way that most databases either don't accept or actively
cleanse malformed unicode strings this vulnerability is most likely to
be exploited by non-persistent attacks however persistent attacks may
still be possible in some configurations.
This affects rubygem-rails in Fedora 10, 11, rawhide, and EPEL 5. Upstream versions fixing the issue for 2.2.x and 2.3.x will be available Sept 3, 2009 after the vulnerability announcement is made.
Created attachment 359553 [details]
patch to fix CVE-2009-3009 in rails 2.1.x
In the event upstream does not push a new 2.1.x release, this patch will correct the issue.
Created attachment 359554 [details]
patch to fix CVE-2009-3009 in rails 2.3.x
Embargo has been lifted:
MITRE's CVE-2009-3009 record:
Cross-site scripting (XSS) vulnerability in Ruby on Rails 2.x before
2.2.3, and 2.3.x before 2.3.4, allows remote attackers to inject
arbitrary web script or HTML by placing malformed Unicode strings into
a form helper.
This issue affects the versions of ruby-activesupport package, as shipped
with Fedora release of 10 and 11. Patch from:
seems to be applicable.
David, any progress while scheduling the updates?
On rawhide: done
Opinions welcome about whether we should upgrade rubygems to 1.3.5
or not (rubygem-rails 2.3.4 requires rubygems >= 1.3.4, current
rubygems on F-11 is 1.3.1), already mailed to rubygem-rails and
rubygem-actionpack-2.1.1-3.fc10,rubygem-activesupport-2.1.1-2.fc10 has been submitted as an update for Fedora 10.
rubygem-actionpack-2.1.1-3.el5,rubygem-activesupport-2.1.1-2.el5 has been submitted as an update for Fedora EPEL 5.
rubygem-actionpack-2.3.3-2.fc11,rubygem-activesupport-2.3.3-2.fc11 has been submitted as an update for Fedora 11.
rawhide: comment 9
F-11: comment 12
F-10: comment 11
EL-5: comment 10
(In reply to comment #13)
F-10: comment 10
EL-5: comment 11
rubygem-actionpack-2.1.1-3.el5, rubygem-activesupport-2.1.1-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.
rubygem-actionpack-2.1.1-3.fc10, rubygem-activesupport-2.1.1-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
rubygem-actionpack-2.3.3-2.fc11, rubygem-activesupport-2.3.3-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
All branches fixed.
Not fixed on F-11, due to a bunch of rubygem-* packages having versioned requirements on rubygem-actionpack-2.3.2. Such packages include:
I am not really familiar with the Ruby and the Rails stuff, but I guess this security update should be installable in some way.
BTW, a similar issue appears with the versioned dependencies on rubygem-actionpack.
rubygem-activerecord-2.3.3-2.fc11,rubygem-activeresource-2.3.3-2.fc11,rubygem-rails-2.3.3-3.fc11,rubygem-actionmailer-2.3.3-3.fc11 has been submitted as an update for Fedora 11.
If you push this update and everyone upgrades to Rails 2.3.3, existing
applications will break because of this piece of the default
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.2' unless defined? RAILS_GEM_VERSION
The Rails version shouldn't be bumped in F11. You're not even attempting
to go to the current version of Rails upstream. The security patches
apply just fine to 2.3.2, and that's what should have been patched here.
The only reason 2.3.3 is being pushed now is that kanarip imported new
sources, and never pushed them out to the distro, so when a rebuild
happened for this security patch, it's causing everyone to be upgraded
to 2.3.3. Please back out to 2.3.2 and apply the security patch there.
You can set RAILS_GEM_VERSION environment then, so no problem.
Honestly saying, I think if a software which expects just rubygem-rails = 2.3.2
and fails suddenly with 2.3.4 it is a serious bug in the software. It is highly
expected that another bugs, not specific to security issues, will be found
on rails and another bug fix releases with minor release number bump will
be released at the time. At that time, postponeing bug fix of rails on Fedora
because some software cannot handle such minor release bump of rails
while rails' API does not change is certainly a bug in that software
and that software must be fixed.
Also rubygem-activesupport 2.3.3 is already pushed and we cannot revert
Mamoru, I believe you're misunderstanding the problem. Yes, if
everyone with an existing application goes and sets the
RAILS_GEM_VERSION environment variable, or edits the environment.rb
file, their application will once again work unless it has a serious
bug. That's not the point.
The point is that the restriction to 2.3.2 in environment.rb is
set up *by default* when you first run 'rails' to initialize an
application. This means that anyone who has set up a rails app
on Fedora 11 will have their app stop working when they take this
update, until they notice that their app has broken and go make
the change. It is irresponsible for the maintainers of a package
to push an update that pointlessly breaks most existing applications.
Fedora 12 is due out very soon now, and that would be the right
time to push a backwards-incompatible update. You could argue that
Rails has a bug in that its default framework ties to you a hardcoded
version, and I'd agree with you - it should be possible to upgrade
the package version without breaking your application. The software
that needs to be fixed is Rails, because it will break applications
on upgrade that should be perfectly compatible with the new version.
The only people who were able to successfully take the rubygem-activesupport
2.3.3 update were the ones who don't have rubygem-rails installed,
which is probably not many people, or the ones running packages out
of updates-testing, who expect some updates to not work. You could
back out to 2.3.2 by bumping the epoch of the package, and I urge
you to consider doing so. You've attempted to push a software version
change as a security update, when in fact the security patch isn't
included in the version you're updating to (so you had to manually
apply it), and it applies cleanly to the version of the software
currently in the release.
I agree that we shouldn't break existing apps with an update (and I am firmly pointing my finger at upstream rails for the insanity of hardcoding version numbers to avoid any semblancce of API stability)
I am revoking the push request for now, and will see about pushing a patched 2.3.2 into F-11 on Monday.
Thank you very much. I'm presently running locally built 2.3.2 packages
with the same patch that you folks applied to 2.3.3, and it seems to
work fine. Let me know if you'd like any assistance testing what you
come up with.
Also, I see that you added a negative comment to Bodhi, though it
still lists the status as "pending." Is this just a bug in the Bodhi
display, or was the revocation unsuccessful?
rubygem-actionmailer-2.3.2-3.fc11,rubygem-actionpack-2.3.2-2.fc11,rubygem-activerecord-2.3.2-2.fc11,rubygem-activeresource-2.3.2-2.fc11,rubygem-activesupport-2.3.2-2.fc11,rubygem-rails-2.3.2-5.fc11 has been submitted as an update for Fedora 11.
rubygem-actionmailer-2.3.2-3.fc11, rubygem-actionpack-2.3.2-2.fc11, rubygem-activerecord-2.3.2-2.fc11, rubygem-activeresource-2.3.2-2.fc11, rubygem-activesupport-2.3.2-2.fc11, rubygem-rails-2.3.2-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
I guess this one is already fixed.