Re: Homakov-esque Django Vulnerabilities

[Masklinn]

On 2012-03-07, at 07:53 , Peter Murphy wrote:

> 
> 
> On Mar 7, 10:13 am, Donald Stufft  wrote:
>> 
>> For what it's worth in the context of the Homakov exploit, this has been a 
>> well known vulnerability by the rails core for years
>> that they've basically said "not our problem, configure your app better" the 
>> entire time. I think that situation is the one that
>> Joey was referring too.
> 
> I hope that Django has no vulnerabilities of the "WTFitude" that Ruby
> on Rails has with "mass assignment" vulnerabilities. I got this link
> from Homakov's github complaint[1].
> 
> http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1
> 
> "If you’re using Rails and you want to be secure, you should be
> protecting against mass assignment. Basically, without declaring
> attr_accessible or attr_protected, malicious users can set any column
> value in your database, including foreign keys and secure data."
> 
> Huh? (With a side helping of jaw dropping.) Why would you allow your
> users to get anywhere near the DB code?

You do that any time you create an object using POSTdata (which you
should not do). That's how "near the DB code" this comes, the code
essentially does the same thing as `Model(**request.POST)… except it
can also work for updates. And that's a normal rails idiom apparently.

> Why should it be even
> possible? Why would "magic" attributes make a difference?

"Mass assignment" works through a dedicated method
(ActiveRecord::Base#update_attributes). ``attr_accessible`` and
``attr_protected`` control the behavior of this method by respectively
whitelisting and blacklisting fields the method can touch. That's why
these attributes make a difference: by using ``attr_accessible`` (the
other one should not be used) you define any attribute which is "safe"
to update.

> In Django, you abstract the models code (which reads and writes DB
> records) from the views (where all the monkey business could occur)
> from the urls. At least that's what I thought you should do. You also
> make the views in charge of checking whether your requests are POSTs
> or GETs.

It's the same in Rails (modulo a few things), the issue here is at the
point where you move data from the view to the model, and Rails's
"ethos" of doing data validation in the model rather than the view when
possible. Django tends to have much lower a hangup on implicit behavior
(so between a potentially dangerous implicit behavior and a safer
explicit one, Django will not implement the implicit and require
explicitness) and modelforms act as fields whitelists (even more so
because they're easy to compose).

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

Re: Homakov-esque Django Vulnerabilities

[Peter Murphy]

On Mar 7, 10:13 am, Donald Stufft  wrote:
>
> For what it's worth in the context of the Homakov exploit, this has been a 
> well known vulnerability by the rails core for years
> that they've basically said "not our problem, configure your app better" the 
> entire time. I think that situation is the one that
> Joey was referring too.

I hope that Django has no vulnerabilities of the "WTFitude" that Ruby
on Rails has with "mass assignment" vulnerabilities. I got this link
from Homakov's github complaint[1].

http://enlightsolutions.com/articles/whats-new-in-edge-scoped-mass-assignment-in-rails-3-1

"If you’re using Rails and you want to be secure, you should be
protecting against mass assignment. Basically, without declaring
attr_accessible or attr_protected, malicious users can set any column
value in your database, including foreign keys and secure data."

Huh? (With a side helping of jaw dropping.) Why would you allow your
users to get anywhere near the DB code? Why should it be even
possible? Why would "magic" attributes make a difference?

In Django, you abstract the models code (which reads and writes DB
records) from the views (where all the monkey business could occur)
from the urls. At least that's what I thought you should do. You also
make the views in charge of checking whether your requests are POSTs
or GETs. Okay, this depends on the programmer to do the right thing,
but programmers are encouraged to do the right thing by the
framework.  You could set up a vulnerability that allows attackers to
add every British PM in your Users model (from Walpole to Cameron) via
a GET request. But you'd have to sabotage your own code to do so.

Or am I missing something?

Best regards,
Peter



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

Re: Homakov-esque Django Vulnerabilities

[Donald Stufft]

On Tuesday, March 6, 2012 at 7:11 PM, Russell Keith-Magee wrote:
> 
> On 07/03/2012, at 7:55 AM, Joey Espinosa wrote:
> 
> > I agree with you on some of your points. Security can be improved if people 
> > would email the support team INSTEAD OF filing a bug report (this goes for 
> > any project), so that the teams know about security bugs before anybody 
> > else finds them.
> > 
> > However, if there's a default setting or commonly set configuration choice 
> > that may be questionable for security, the best course of action would be 
> > to educate the Django developers and site maintainers on why it is or is 
> > not a good idea to implement. The Rails community has mentioned the Homakov 
> > vulnerability to the Rails team, to which their stance has been 
> > configuration over convention (you're responsible for your own security).
> > 
> > If there's a similar situation with the Django code, and it's something 
> > that's been put in intentionally by the Django team, then why not educate 
> > people about this? Better to have a resource somewhere where at least one 
> > Django developer on a team might have read a good security tip and share it 
> > with his team, than to have a potential attacker figure it out and exploit 
> > all of the Django sites that may have overlooked it. To put it in real life 
> > terms, you don't combat identity theft by not talking about it, you combat 
> > it by providing resources to educate the general public about how to 
> > protect themselves.
> 
> Completely agreed that then education is key. However, the key statement in 
> your reply is "something that's been put in intentionally by the Django 
> team". 
> 
> All I'm asking is before anyone starts broadcasting details about a 
> "vulnerability", that they take the time to contact the core team on 
> secur...@djangoproject.com (mailto:secur...@djangoproject.com) to determine 
> whether the code and it's side effects actually *are* intentional. You 
> *might* have discovered something that has been done intentionally, with full 
> knowledge of the consequences. It *might* be a case where we need to rely on 
> education -- improve Django's own docs, and encourage people like yourself to 
> blog about how to "do it right". However, it might also be a case where we 
> hadn't fully considered all the consequences, in which case, we'd like the 
> opportunity to address the problem before it becomes widespread public 
> knowledge.
> 
> In short -- err on the side of caution. It costs nothing to mail 
> secur...@djangoproject.com (mailto:secur...@djangoproject.com). If you have 
> found a serious problem, we'll give credit where it's due. If not, we'll let 
> you know you can start educating the world about what they're doing wrong.
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com 
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com 
> (mailto:django-users+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
> 
> 

For what it's worth in the context of the Homakov exploit, this has been a well 
known vulnerability by the rails core for years
that they've basically said "not our problem, configure your app better" the 
entire time. I think that situation is the one that
Joey was referring too. 

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

Re: Homakov-esque Django Vulnerabilities

[Russell Keith-Magee]

On 07/03/2012, at 7:55 AM, Joey Espinosa wrote:

> I agree with you on some of your points. Security can be improved if people 
> would email the support team INSTEAD OF filing a bug report (this goes for 
> any project), so that the teams know about security bugs before anybody else 
> finds them.
> 
> However, if there's a default setting or commonly set configuration choice 
> that may be questionable for security, the best course of action would be to 
> educate the Django developers and site maintainers on why it is or is not a 
> good idea to implement. The Rails community has mentioned the Homakov 
> vulnerability to the Rails team, to which their stance has been configuration 
> over convention (you're responsible for your own security).
> 
> If there's a similar situation with the Django code, and it's something 
> that's been put in intentionally by the Django team, then why not educate 
> people about this? Better to have a resource somewhere where at least one 
> Django developer on a team might have read a good security tip and share it 
> with his team, than to have a potential attacker figure it out and exploit 
> all of the Django sites that may have overlooked it. To put it in real life 
> terms, you don't combat identity theft by not talking about it, you combat it 
> by providing resources to educate the general public about how to protect 
> themselves.

Completely agreed that then education is key. However, the key statement in 
your reply is "something that's been put in intentionally by the Django team". 

All I'm asking is before anyone starts broadcasting details about a 
"vulnerability", that they take the time to contact the core team on 
secur...@djangoproject.com to determine whether the code and it's side effects 
actually *are* intentional. You *might* have discovered something that has been 
done intentionally, with full knowledge of the consequences. It *might* be a 
case where we need to rely on education -- improve Django's own docs, and 
encourage people like yourself to blog about how to "do it right". However, it 
might also be a case where we hadn't fully considered all the consequences, in 
which case, we'd like the opportunity to address the problem before it becomes 
widespread public knowledge.

In short -- err on the side of caution. It costs nothing to mail 
secur...@djangoproject.com. If you have found a serious problem, we'll give 
credit where it's due. If not, we'll let you know you can start educating the 
world about what they're doing wrong.

Yours,
Russ Magee %-)

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

Re: Homakov-esque Django Vulnerabilities

[Joey Espinosa]

I agree with you on some of your points. Security can be improved if people
would email the support team INSTEAD OF filing a bug report (this goes for
any project), so that the teams know about security bugs before anybody
else finds them.

However, if there's a default setting or commonly set configuration choice
that may be questionable for security, the best course of action would be
to educate the Django developers and site maintainers on why it is or is
not a good idea to implement. The Rails community has mentioned the Homakov
vulnerability to the Rails team, to which their stance has been
configuration over convention (you're responsible for your own security).

If there's a similar situation with the Django code, and it's something
that's been put in intentionally by the Django team, then why not educate
people about this? Better to have a resource somewhere where at least one
Django developer on a team might have read a good security tip and share it
with his team, than to have a potential attacker figure it out and exploit
all of the Django sites that may have overlooked it. To put it in real life
terms, you don't combat identity theft by not talking about it, you combat
it by providing resources to educate the general public about how to
protect themselves.

Literally three days ago I found a potential vulnerability (a pretty stupid
one too) on a large site built on another similar platform (not Django), so
I emailed the support team and informed them of the possible security hole.
It happens, but it's better to make sure people can be educated and learn.
--
Joey "JoeLinux" Espinosa*
*





On Tue, Mar 6, 2012 at 6:16 PM, Russell Keith-Magee  wrote:

>
> On 06/03/2012, at 8:31 PM, Joey Espinosa wrote:
>
> > In light of all the recent talk about Egor Homakov's commandeering of
> GitHub by exploiting a default Rails setting, are there any such "gotcha"
> security defaults or common settings/conventions in Django you can think of
> that could cause unsuspecting site maintainers to suffer a similar fate? If
> you have a good one (or better yet, a list), sound off! This could help
> other developers/administrators, and I could collect these into a blog post
> if I get enough responses.
>
> Perhaps the biggest lesson the open source community can learn from this
> entire exercise is *how to report security issues*.
>
> If you find -- or even *suspect* that you have found -- a security
> vulnerability in Django, *please* don't file a bug, write a blog post, or
> deface a known Django site. You should mail security@djangoproject.comand 
> describe in detail the problem you have found.
>
> The same goes for "insecure-by-default" defaults -- if you think Django
> has a default option that has the potential to leave Django sites
> accidentally vulnerable, *please* don't post a blog explaining how to
> identify and exploit the problem. Mail secur...@djangoproject.com and
> describe the problem. This class of problem is harder to protect against,
> because we can't always protect against how someone will use a library. But
> if it's in our power to provide a secure default, or provide better
> documentation to encourage best practice, or even just document that a
> potential gotcha exists, we would like to do so -- without the fireworks
> that the Rails and Github communities were forced to endure this week.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

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

Re: Homakov-esque Django Vulnerabilities

[Russell Keith-Magee]

On 06/03/2012, at 8:31 PM, Joey Espinosa wrote:

> In light of all the recent talk about Egor Homakov's commandeering of GitHub 
> by exploiting a default Rails setting, are there any such "gotcha" security 
> defaults or common settings/conventions in Django you can think of that could 
> cause unsuspecting site maintainers to suffer a similar fate? If you have a 
> good one (or better yet, a list), sound off! This could help other 
> developers/administrators, and I could collect these into a blog post if I 
> get enough responses.

Perhaps the biggest lesson the open source community can learn from this entire 
exercise is *how to report security issues*.

If you find -- or even *suspect* that you have found -- a security 
vulnerability in Django, *please* don't file a bug, write a blog post, or 
deface a known Django site. You should mail secur...@djangoproject.com and 
describe in detail the problem you have found. 

The same goes for "insecure-by-default" defaults -- if you think Django has a 
default option that has the potential to leave Django sites accidentally 
vulnerable, *please* don't post a blog explaining how to identify and exploit 
the problem. Mail secur...@djangoproject.com and describe the problem. This 
class of problem is harder to protect against, because we can't always protect 
against how someone will use a library. But if it's in our power to provide a 
secure default, or provide better documentation to encourage best practice, or 
even just document that a potential gotcha exists, we would like to do so -- 
without the fireworks that the Rails and Github communities were forced to 
endure this week.

Yours,
Russ Magee %-)

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