Homakov-esque Django Vulnerabilities
Joey Espinosa
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 secu...@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 secu...@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 %-)
Joey Espinosa
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
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 secu...@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 secu...@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 %-)
Donald Stufft
--You received this message because you are subscribed to the Google Groups "Django users" group.To post to this group, send email to django...@googlegroups.com.To unsubscribe from this group, send email to django-users...@googlegroups.com.For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Peter Murphy
On Mar 7, 10:13 am, Donald Stufft <donald.stu...@gmail.com> 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.
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
Masklinn
>
>
> On Mar 7, 10:13 am, Donald Stufft <donald.stu...@gmail.com> 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).