Multiple high security vulnerabilities in Ruby on Rails ActionPack (CVE-2013-0156)

Support
1

Hey guys,

If anyone is using Apache Passenger / Ruby on Rails (which is how the
Foreman Installer sets up the system) you should consider updating some of
the gems immediately. Specifically the ActionPack gem, which will likely
hit you with some dependencies. On my particular system I only needed to
install the following (in order):

I usually like to use RPMs to install these, but they don't seem to have
the latest available for my distro yet so I did it all through gem (gem
install --local <file>)

See more about this vulnerability here, it's particularly ugly and many
have named it as the worst security vulnerability in rails:

https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ

Jason

2

PS: I haven't done much extensive tests yet… so don't know if this will
break Foreman or not. Hoping someone else out there has had an opportunity?
:wink:

Will update as the day goes and when I have a chance to dig into this
further.

··· On Wednesday, January 9, 2013 10:52:52 AM UTC-5, Jason Knudsen wrote: > > Hey guys, > > If anyone is using Apache Passenger / Ruby on Rails (which is how the > Foreman Installer sets up the system) you should consider updating some of > the gems immediately. Specifically the ActionPack gem, which will likely > hit you with some dependencies. On my particular system I only needed to > install the following (in order): > > - sprockets: http://rubygems.org/downloads/sprockets-2.2.1.gem > - activesupport: http://rubygems.org/downloads/activesupport-3.2.11.gem > - activemodel: http://rubygems.org/downloads/activemodel-3.2.11.gem > - actionpack: http://rubygems.org/downloads/actionpack-3.2.11.gem > > I usually like to use RPMs to install these, but they don't seem to have > the latest available for my distro yet so I did it all through gem (gem > install --local ) > > See more about this vulnerability here, it's particularly ugly and many > have named it as the worst security vulnerability in rails: > > > https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ > > Jason >
3

Hi Jason,

> If anyone is using Apache Passenger / Ruby on Rails (which is how the
> Foreman Installer sets up the system) you should consider updating some
> of the gems immediately. Specifically the ActionPack gem, which will
> likely hit you with some dependencies. On my particular system I only
> needed to install the following (in order):
>
> * sprockets: http://rubygems.org/downloads/sprockets-2.2.1.gem
> * activesupport: http://rubygems.org/downloads/activesupport-3.2.11.gem
> * activemodel: http://rubygems.org/downloads/activemodel-3.2.11.gem
> * actionpack: http://rubygems.org/downloads/actionpack-3.2.11.gem
>
> I usually like to use RPMs to install these, but they don't seem to have
> the latest available for my distro yet so I did it all through gem (gem
> install --local <file>)

I'd really recommend against this upgrade, since it moves to Rails 3.2.
Foreman currently works with Rails 3.0, so you'd want version 3.0.19
instead. I expect we'll be updating the 1.0 branch (Sam, Greg?).

The Rails vulnerability has made us realise there's a very similar issue
in Foreman itself where it parses untrusted YAML input, which we're now
looking to address. Any feedback on the proposal below would be
appreciated, before we implement it.

The facts and reports importers are used by puppetmasters to send YAML
to Foreman, which is imported straight from Puppet and without any
authentication (since the puppetmaster has no credentials). An attacker
can use this YAML loading to exploit Foreman.

We're proposing to lock this down so that only hosts with registered
smart proxies on (with the Puppet feature) are able to upload data.

In addition, we would recommend (and implement in foreman-installer)
enabling optional client SSL cert verification in mod_ssl, then enforce
the smart proxy check using the client certificate's CN. The report and
ENC scripts would change to use the puppetmaster's SSL cert during HTTPS
calls to Foreman.

Both the host check and the enhanced HTTPS check would have settings so
they can be disabled. They'd be enabled by default in 1.1, but if
there's demand for a backport to 1.0 then they'd be disabled for
compatibility.

This would also address the issue raised by Andreas Rogge (thank you for
the report) where ENC output, including hashed root passwords, is
accessible to any host: Bug #2069: (encrypted) root passwords are world readable - Foreman

In the meantime, if you're concerned about the security of your Foreman
host then you could restrict access via Apache, if you use it. e.g.

<Location ~ "/(fact_values|reports)/create">
Order Deny,Allow
Deny from all
Allow from puppetmaster.example.net
</Location>

··· On 09/01/13 15:52, Jason Knudsen wrote:

–
Dominic Cleal
Red Hat Engineering

4

Hey Dominic,

Thanks for the update, very appreciated. The workaround with Apache Vhost
is a good solution to get us locked down. In the meantime, let me know if
you want some help testing out fixed versions.

Regarding your proposal: makes total sense. We have the foreman-proxy on
the same server as our foreman instance anyway and if we ever needed to
scale out, that should be a requirement to install.

We'll be moving to 1.1 as soon as it becomes available, so I don't mind it
not being backported. I've already been working on migrating our stuff over
to 1.1 and updating our puppet modules for 3. So far, so good.

Thanks,

Jason

··· On Wednesday, January 9, 2013 11:45:24 AM UTC-5, Dominic Cleal wrote: > > Hi Jason, > > On 09/01/13 15:52, Jason Knudsen wrote: > > If anyone is using Apache Passenger / Ruby on Rails (which is how the > > Foreman Installer sets up the system) you should consider updating some > > of the gems immediately. Specifically the ActionPack gem, which will > > likely hit you with some dependencies. On my particular system I only > > needed to install the following (in order): > > > > * sprockets: http://rubygems.org/downloads/sprockets-2.2.1.gem > > * activesupport: > http://rubygems.org/downloads/activesupport-3.2.11.gem > > * activemodel: http://rubygems.org/downloads/activemodel-3.2.11.gem > > * actionpack: http://rubygems.org/downloads/actionpack-3.2.11.gem > > > > I usually like to use RPMs to install these, but they don't seem to have > > the latest available for my distro yet so I did it all through gem (gem > > install --local ) > > I'd really recommend against this upgrade, since it moves to Rails 3.2. > Foreman currently works with Rails 3.0, so you'd want version 3.0.19 > instead. I expect we'll be updating the 1.0 branch (Sam, Greg?). > > The Rails vulnerability has made us realise there's a very similar issue > in Foreman itself where it parses untrusted YAML input, which we're now > looking to address. Any feedback on the proposal below would be > appreciated, before we implement it. > > The facts and reports importers are used by puppetmasters to send YAML > to Foreman, which is imported straight from Puppet and without any > authentication (since the puppetmaster has no credentials). An attacker > can use this YAML loading to exploit Foreman. > > We're proposing to lock this down so that only hosts with registered > smart proxies on (with the Puppet feature) are able to upload data. > > In addition, we would recommend (and implement in foreman-installer) > enabling optional client SSL cert verification in mod_ssl, then enforce > the smart proxy check using the client certificate's CN. The report and > ENC scripts would change to use the puppetmaster's SSL cert during HTTPS > calls to Foreman. > > Both the host check and the enhanced HTTPS check would have settings so > they can be disabled. They'd be enabled by default in 1.1, but if > there's demand for a backport to 1.0 then they'd be disabled for > compatibility. > > This would also address the issue raised by Andreas Rogge (thank you for > the report) where ENC output, including hashed root passwords, is > accessible to any host: http://theforeman.org/issues/2069 > > In the meantime, if you're concerned about the security of your Foreman > host then you could restrict access via Apache, if you use it. e.g. > > > Order Deny,Allow > Deny from all > Allow from puppetmaster.example.net > > > -- > Dominic Cleal > Red Hat Engineering >
5

Yo,

Just an update on this thread about updating ActionPack. I updated the
gem's:

actionpack 3.0.19
activemodel 3.0.19
activesupport 3.0.19

All is well in Foreman and Puppet land. At least those holes have been
fixed!

Thanks,

Jason

··· On Wednesday, January 9, 2013 12:11:29 PM UTC-5, Jason Knudsen wrote: > > Hey Dominic, > > Thanks for the update, very appreciated. The workaround with Apache Vhost > is a good solution to get us locked down. In the meantime, let me know if > you want some help testing out fixed versions. > > Regarding your proposal: makes total sense. We have the foreman-proxy on > the same server as our foreman instance anyway and if we ever needed to > scale out, that should be a requirement to install. > > We'll be moving to 1.1 as soon as it becomes available, so I don't mind it > not being backported. I've already been working on migrating our stuff over > to 1.1 and updating our puppet modules for 3. So far, so good. > > Thanks, > > Jason > > On Wednesday, January 9, 2013 11:45:24 AM UTC-5, Dominic Cleal wrote: >> >> Hi Jason, >> >> On 09/01/13 15:52, Jason Knudsen wrote: >> > If anyone is using Apache Passenger / Ruby on Rails (which is how the >> > Foreman Installer sets up the system) you should consider updating some >> > of the gems immediately. Specifically the ActionPack gem, which will >> > likely hit you with some dependencies. On my particular system I only >> > needed to install the following (in order): >> > >> > * sprockets: http://rubygems.org/downloads/sprockets-2.2.1.gem >> > * activesupport: >> http://rubygems.org/downloads/activesupport-3.2.11.gem >> > * activemodel: http://rubygems.org/downloads/activemodel-3.2.11.gem >> > * actionpack: http://rubygems.org/downloads/actionpack-3.2.11.gem >> > >> > I usually like to use RPMs to install these, but they don't seem to >> have >> > the latest available for my distro yet so I did it all through gem (gem >> > install --local ) >> >> I'd really recommend against this upgrade, since it moves to Rails 3.2. >> Foreman currently works with Rails 3.0, so you'd want version 3.0.19 >> instead. I expect we'll be updating the 1.0 branch (Sam, Greg?). >> >> The Rails vulnerability has made us realise there's a very similar issue >> in Foreman itself where it parses untrusted YAML input, which we're now >> looking to address. Any feedback on the proposal below would be >> appreciated, before we implement it. >> >> The facts and reports importers are used by puppetmasters to send YAML >> to Foreman, which is imported straight from Puppet and without any >> authentication (since the puppetmaster has no credentials). An attacker >> can use this YAML loading to exploit Foreman. >> >> We're proposing to lock this down so that only hosts with registered >> smart proxies on (with the Puppet feature) are able to upload data. >> >> In addition, we would recommend (and implement in foreman-installer) >> enabling optional client SSL cert verification in mod_ssl, then enforce >> the smart proxy check using the client certificate's CN. The report and >> ENC scripts would change to use the puppetmaster's SSL cert during HTTPS >> calls to Foreman. >> >> Both the host check and the enhanced HTTPS check would have settings so >> they can be disabled. They'd be enabled by default in 1.1, but if >> there's demand for a backport to 1.0 then they'd be disabled for >> compatibility. >> >> This would also address the issue raised by Andreas Rogge (thank you for >> the report) where ENC output, including hashed root passwords, is >> accessible to any host: http://theforeman.org/issues/2069 >> >> In the meantime, if you're concerned about the security of your Foreman >> host then you could restrict access via Apache, if you use it. e.g. >> >> >> Order Deny,Allow >> Deny from all >> Allow from puppetmaster.example.net >> >> >> -- >> Dominic Cleal >> Red Hat Engineering >> >