Critical security update for tg2 users!

[Mark Ramm]

We recently discovered that TurboGears2 ships with quickstart configuration that leaves users of it's default user authorization/authentication scheme vulnerable to a serious security issue. 

If you are running a TG2 application in production you are strongly encouraged to set the cookie salt for the authorization cookie in repoze.who to something other than it's default value. 

This is simple enough to do, just set base_config.sa_auth.cookie_secret to any secret value you'd like.   For example: 

base_config.sa_auth.cookie_secret = "mynewsecret" 

You can also set it in development.ini using a key like:

sa_auth.cookie_secret = "mysupersecret" 

Failure to do this could leave you vulnerable to someone who knows the default cookie secret being able to craft a cookie that allows a user into your site without authenticating through the normal mechanism. 

TurboGears 2.0.2 will enforce setting the cookie secret and will refuse to run if you have not set that value in your configuration.   We've just released 2.0.2, which also fixes another security issue which could cause controller methods decorated with something other than @expose to still be exposed through the URL dispatch mechanism.

You can update to 2.0.2 with 

easy_install -Ui http://turbogears.org/2.0/downloads/current/ turbogears2

--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

[Jorge Vargas]

Small correction, on my linux box you need

easy_install -Ui http://turbogears.org/2.0/downloads/current/ TurboGears2

note the caps.

[Mark Ramm]

I messed up the 2.0.2 egg in an svn merge mistake, so we've now
relesed 2.0.3 with a fix. Install instructions are the same.

[Lukasz Szybalski]

On Tue, Aug 11, 2009 at 8:16 PM, Mark Ramm<mark.mch...@gmail.com> wrote:
> We recently discovered that TurboGears2 ships with quickstart configuration
> that leaves users of it's default user authorization/authentication scheme
> vulnerable to a serious security issue.
> If you are running a TG2 application in production you are strongly
> encouraged to set the cookie salt for the authorization cookie in repoze.who
> to something other than it's default value.
> This is simple enough to do, just set base_config.sa_auth.cookie_secret to
> any secret value you'd like.   For example:
> base_config.sa_auth.cookie_secret = "mynewsecret"
> You can also set it in development.ini using a key like:
> sa_auth.cookie_secret = "mysupersecret"
> Failure to do this could leave you vulnerable to someone who knows the
> default cookie secret being able to craft a cookie that allows a user into
> your site without authenticating through the normal mechanism.
> TurboGears 2.0.2 will enforce setting the cookie secret and will refuse to
> run if you have not set that value in your configuration.

Can this be done automatically just like the beaker.session.secret is
set when doing:

paster make-config myapp production.ini

25 beaker.session.secret = ${app_instance_secret}

Thanks,
Lucas

--
Using rsync. How to setup rsyncd.
http://lucasmanual.com/mywiki/rsync
OpenLdap - From start to finish.
http://lucasmanual.com/mywiki/OpenLdap

[Antoine Pitrou]

On Aug 12, 3:16 am, Mark Ramm <mark.mchristen...@gmail.com> wrote:
>
> This is simple enough to do, just set base_config.sa_auth.cookie_secret to
> any secret value you'd like.   For example:
>
> base_config.sa_auth.cookie_secret = "mynewsecret"

Ouch, so this is something different than beaker.session.secret ?

I thought all this was somehow using a shared code base, and didn't
know that the auth system had its own separate salt (and it's not like
the docs warn you about this, it seems)... :-/

[Antoine Pitrou]

On Aug 12, 3:16 am, Mark Ramm <mark.mchristen...@gmail.com> wrote:

> You can also set it in development.ini using a key like:
>
> sa_auth.cookie_secret = "mysupersecret"

In [app:main] I assume?

[El Tea]

I could really use a pointer to a set of documentation somewhere that
lists all the requirements for securing my site. I would think it
would include changing this "secret", getting the site out of debug
mode, and maybe even validating every form (even if you don't assign a
validator to a field - which I am hoping escapes injection attacks).

I expect TG is used by many professionals - but many people like
myself as well, who are not well experienced in web architectures and
SQL. That's why I use TG - to abstract away and simplify, but I feel
like it may leave my site and/or database open to vulnerabilities
because I don't grasp all the nuances.

My previous approach was to buy Mark's book - and it was great, but
I've since moved on to TG2. Is there any page of mandatory steps and
best practices to properly secure a TG2 site?


Mike

[Jorge Vargas]

On Wed, Aug 12, 2009 at 10:38 PM, El Tea<the.e...@gmail.com> wrote:
>
The biggest problem with answering this is that you may be doing bad
things that are complete away from TG. For example there is no way for
TG to validate that you are not storing creditcard data in your
database.

> I could really use a pointer to a set of documentation somewhere that
> lists all the requirements for securing my site.  I would think it
> would include changing this "secret", getting the site out of debug
> mode, and maybe even validating every form (even if you don't assign a
> validator to a field - which I am hoping escapes injection attacks).
>

Injection attacks are something that is caught at the SA level. In
theory it's query builder and object layer will catch all attempts at
it. I say in theory because a bug may be found or you could be using
sqlalchemy.sql.TEXT

> I expect TG is used by many professionals - but many people like
> myself as well, who are not well experienced in web architectures and
> SQL.  That's why I use TG - to abstract away and simplify, but I feel
> like it may leave my site and/or database open to vulnerabilities
> because I don't grasp all the nuances.
>

Sadly this is not a TG issue. And even though I agree TG should tell
you all you need to do to close the holes TG opens we can't tell you
how to close the holes you open.

> My previous approach was to buy Mark's book - and it was great, but
> I've since moved on to TG2.  Is there any page of mandatory steps and
> best practices to properly secure a TG2 site?
>

I don't think there is. That should be a chapter on the deployment guides.

[Derick Eisenhardt]

This upgrade system doesn't seem to work very well, or at least not as
expected. First off, it needs to be:

easy_install -Ui http://turbogears.org/2.0/downloads/current/index/
TurboGears2

to actually pull 2.0.3, without index in the URL it doesn't seem to
really do anything. Secondly it only updates that one package, but
none of its dependencies...after preforming both versions, my Repoze
installed is still at 1.0.10, when it should be now at 1.0.15.
Personally, I'm just gonna do a new virtual environment with a fresh
install...but would be nice to be able to upgrade All :/

(cross posted from trunk list)

On Aug 13, 3:22 am, Jorge Vargas <jorge.var...@gmail.com> wrote:

[Antoine Pitrou]

On Aug 13, 5:57 pm, Derick Eisenhardt <derick.eisenha...@gmail.com>
wrote:

> Secondly it only updates that one package, but
> none of its dependencies...after preforming both versions, my Repoze
> installed is still at 1.0.10, when it should be now at 1.0.15.

`yolk` is a nice tool to know which packages have higher versions
available (`yolk -U`).
Then you can explicitly upgrade each one of them individually if you
want.

[cd34]

On Aug 13, 11:57 am, Derick Eisenhardt <derick.eisenha...@gmail.com>
wrote:

> really do anything. Secondly it only updates that one package, but
> none of its dependencies...after preforming both versions, my Repoze

That's actually a plus. With the long delay between bug reports and
actual fixes, it saves time from having to constantly repatch the
dependencies.

While the 'patch' fixes the initially reported problem, repoze is
still quite insecure.

[Gustavo Narea]

cd34 said:
> While the 'patch' fixes the initially reported problem, repoze is
> still quite insecure.

First of all, Repoze is a community that develops many projects and TurboGears
doesn't even use a half of them.

Now, I guess you meant to say repoze.who and/or repoze.what and/or their
plugins. So, what's the matter with them?
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |

[El Tea]

Thanks. I'm assuming that sqlalchemy.sql.text is for storing actual
sql? In other words, all the basics should be good? (I'm thinking
Unicode and UnicodeText for the most part.)

Understood that you can't point me to the holes *I* open up, but a
list of the ones you have to close off yourself, plus a list of common
mistakes or points of failure I would think would still be of
significant use to a newcomer (and as you note, this would be useful
in the deployment guides).

All that being said - if someone was to build a site dealing with
financial transactions and they want to keep an customer's credit card
on file for future use, wouldn't it be stored in a database? Where
the heck does Amazon keep it? (Note that I have no intention of doing
this; you've piqued my curiosity!)

On Aug 13, 4:22 am, Jorge Vargas <jorge.var...@gmail.com> wrote:

[Diez B. Roggisch]

El Tea schrieb:

> Thanks. I'm assuming that sqlalchemy.sql.text is for storing actual
> sql? In other words, all the basics should be good? (I'm thinking
> Unicode and UnicodeText for the most part.)
>
> Understood that you can't point me to the holes *I* open up, but a
> list of the ones you have to close off yourself, plus a list of common
> mistakes or points of failure I would think would still be of
> significant use to a newcomer (and as you note, this would be useful
> in the deployment guides).
>
> All that being said - if someone was to build a site dealing with
> financial transactions and they want to keep an customer's credit card
> on file for future use, wouldn't it be stored in a database? Where
> the heck does Amazon keep it? (Note that I have no intention of doing
> this; you've piqued my curiosity!)

They might store it, but possibly encrypted so that even someone who has
access to the DB can't read it.

Also, payment is most probably created as service to the overall webapp,
which is more stable, and can be run on much more locked-down machines,
and possibly even with the need to enter a manual password so that only
the running process is capable of deciphering it.

Well, that at least would be the things I'd do - no ide if amazon *does*
do that.

Diez

[alexbod...@gmail.com]

hi mark, that's important improvement.

On Wed, Aug 12, 2009 at 04:16, Mark Ramm<mark.mch...@gmail.com> wrote:
> We recently discovered that TurboGears2 ships with quickstart configuration
> that leaves users of it's default user authorization/authentication scheme
> vulnerable to a serious security issue. 
> If you are running a TG2 application in production you are strongly
> encouraged to set the cookie salt for the authorization cookie in repoze.who
> to something other than it's default value. 

> This is simple enough to do, just set base_config.sa_auth.cookie_secret to
> any secret value you'd like.   For example: 
> base_config.sa_auth.cookie_secret = "mynewsecret" 

> You can also set it in development.ini using a key like:
> sa_auth.cookie_secret = "mysupersecret" 

it's a matter of my misunderstanding of the ini formats, but i failed to set this in my roughly default development.ini.

any idea is welcome.

> Failure to do this could leave you vulnerable to someone who knows the
> default cookie secret being able to craft a cookie that allows a user into
> your site without authenticating through the normal mechanism. 
> TurboGears 2.0.2 will enforce setting the cookie secret and will refuse to
> run if you have not set that value in your configuration.

>   We've just released 2.0.2, which also fixes another security issue which could cause controller methods decorated with something other than @expose to still be exposed through the URL dispatch mechanism.
> You can update to 2.0.2 with 
> easy_install -Ui http://turbogears.org/2.0/downloads/current/ turbogears2

well, this wouldn't work for me too, and i had to specify the tar.gz name manually.

> --
> Mark Ramm-Christensen
> email: mark at compoundthinking dot com
> blog: www.compoundthinking.com/blog
>
>

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.
> To post to this group, send email to turbo...@googlegroups.com
> To unsubscribe from this group, send email to
> turbogears+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/turbogears?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>



--
alex

[dakila]

Hi All,

The easy_install ... TurboGears2 update did not work for me also, I
need to specify the tar.gz manually also.
With regards to adding the cookie_secret, I was only able to do it in
app_cfg.py as I can not make it work using the .ini file

Regards,
Dax

On Aug 16, 7:47 am, alexbodn.gro...@gmail.com wrote:
> hi mark, that's important improvement.
>

> alex
>
>  smime.p7s
> < 1KViewDownload