[katello-devel] ActiveRecord SQL injection and secret_token.rb

Development
1

That's interesting, I hadn't considered it. I don't know how
significant it is though.

We already have the Rails cache under tmp/, which is writeable, so must
everything under there deemed untrusted user input? Settings are
cached, so if an attacker has write access to the cache they should be
able to disable various authorisation settings. Maybe they can get
admin access through that alone, without needing to compromise cookie
security.

To directly address your point, the token will be generated by the
packages too in the way you describe:

This will be used instead of any token generated under tmp/, so for the
packages, I think it's secure enough.

Cheers,
Dom

··· On 09/01/13 08:13, Lukas Zapletal wrote: > I don't think it is good idea to let the Foreman process itself to > generate the token. I would stick with external generation. > > This way, even when running under SELinux, if Foreman is compromised and > attacker is able to save a file through it, he could overwrite it > waiting until instance is restarted and carrying on with the attack > then. > > Having this separate process (e.g. RPM packager) SELinux would prevent > from touching file from different context. This is what we do plus there > is condition - if the file is (for whatever reason) missing or the > content is zero-length, Katello will generate random secret_token each > start (killing all the sessions essentially) > > LZ > > On Tue, Jan 08, 2013 at 10:38:23AM -0500, Ohad Levy wrote: >> for the record, we solved it differently for foreman too :) >> >> see https://github.com/theforeman/foreman/commit/adfcf8f0fa17dd352588fbd9eb24286502ccc90f >> >> Ohad >> >> ----- Original Message ----- >> > >> > >> > ----- Original Message ----- >> > > Hi everybody, >> > > >> > > You probably noticed, that there was released new version of Ruby >> > > on >> > > Rails fixing CVE-2012-5664 vulnerability. The details how to >> > > exploit >> > > this vulnerability are very well described at Phusion's blog [1]. >> > > >> > > However, what is more important is, that since your application >> > > secret >> > > token is not that secret, i.e. it is published on github [2], >> > > cookies >> > > of >> > > Aeolus could be faked [3]. Katello seems to do better in this area >> > > [4] >> > > (although it was just quick look into code, not security audit :)). >> > > Please consider narrowing this situation. >> > >> > Just FYI: secret_token in Katello is regenerated at rpm installation. >> > Thanks for heads up! >> > >> > -- Ivan >> > >> > > >> > > Thank you >> > > >> > > >> > > V�t >> > > >> > > >> > > >> > > [1] >> > > http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ >> > > [2] >> > > https://github.com/aeolusproject/conductor/blob/master/src/config/initializers/secret_token.rb#L23 >> > > [3] >> > > http://biggestfool.tumblr.com/post/24049554541/reminder-secret-token-rb-is-named-so-for-a-reason >> > > [4] >> > > https://github.com/Katello/katello/blob/master/src/config/initializers/secret_token.rb >> > > >> > > _______________________________________________ >> > > katello-devel mailing list >> > > katello-devel@redhat.com >> > > https://www.redhat.com/mailman/listinfo/katello-devel >> > > >> > >> > _______________________________________________ >> > katello-devel mailing list >> > katello-devel@redhat.com >> > https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >

–
Dominic Cleal
Red Hat Engineering

2

> That's interesting, I hadn't considered it. I don't know how
> significant it is though.

Indeed, it's is not that significant, I have to admit.

> We already have the Rails cache under tmp/, which is writeable, so must
> everything under there deemed untrusted user input? Settings are
> cached, so if an attacker has write access to the cache they should be
> able to disable various authorisation settings. Maybe they can get
> admin access through that alone, without needing to compromise cookie
> security.

I don't understand what you mean by settings are cached. I would expect
that tmp/ directory is used for temporary upload files and stuff like
that. Not sure what you mean.

> To directly address your point, the token will be generated by the
> packages too in the way you describe:
> https://github.com/theforeman/foreman-rpms/pull/30

Nice work!

LZ

··· On Wed, Jan 09, 2013 at 12:52:46PM +0000, Dominic Cleal wrote:

–
Later,

Lukas “lzap” Zapletal
#katello #systemengine

3

The Rails cache is stored under tmp/, which we use for a few things such
as lookups on the settings model. In theory I think you could edit a
file under tmp/cache/, e.g. something that relaxes security behaviour,
then Foreman would read it back and use that value.

Maybe there's a bit more to it than that, but it seems to me that we
trust the contents of tmp/ today.

··· On 11/01/13 17:16, Lukas Zapletal wrote: > On Wed, Jan 09, 2013 at 12:52:46PM +0000, Dominic Cleal wrote: >> We already have the Rails cache under tmp/, which is writeable, so must >> everything under there deemed untrusted user input? Settings are >> cached, so if an attacker has write access to the cache they should be >> able to disable various authorisation settings. Maybe they can get >> admin access through that alone, without needing to compromise cookie >> security. > > I don't understand what you mean by settings are cached. I would expect > that tmp/ directory is used for temporary upload files and stuff like > that. Not sure what you mean.

–
Dominic Cleal
Red Hat Engineering