11 ms·

Security releases issued

128 points by hrayr 14y ago

jtchang 14y ago
Just upgraded...nothing really broke for me so looks good. Nice to see lots of back porting of the security fixes.
- naiquevin 14y ago
  I too upgraded and everything went smooth except got a "Bad magic number" error[1] while running south migrations. The fix is to delete all .pyc files (even those inside the virtualenv) [1]: http://stackoverflow.com/questions/514371/whats-the-bad-magic-number-error http://stackoverflow.com/questions/514371/whats-the-bad-magi...
gojomo 14y ago
I don't see the usual strong admonition to upgrade ASAP. (For example, the December 10 updates said, "All users are encouraged to upgrade Django immediately." This bulletin does not.) From a quick skim of the 4 fixes, perhaps not all Django sites may be at risk. For example, if they are: already checking the 'Host' header or not using it; not using Formsets; not using multiple tiers of admin users; not using Django's XML (de-)serialization. But, I'm least confident of that last one. Do all Django installs use Django's XML deserialization for something internal/everpresent? Or is this just a risk for users whose apps explicitly do extra XML operations?
- jacobian 14y ago
  These aren't "drop everything, take the site down, upgrade now" issues, so yeah we'd like to save the tone for that sort of thing. ... but seriously, please do upgrade as soon as possible! There's really no such thing as a "minor" security issue when it's 2am and you're being woken 'cause the site's down.
- pindi 14y ago
  No, Django's XML deserialization is not used automatically. It is only used for mass importing objects to the database, which most sites would allow only admin users to do.
- danielweber 14y ago
  Two of the issues are DoS issues, which aren't "drop everything, upgrade now." If you don't trust your admins, the fourth issue is very important, but lots of places put complete trust in them. The first issue is more about not becoming a vector for a phishing attack, AIUI.
deleted 14y ago
[deleted]
wittekm 14y ago
Interesting that one of the bugs was reported by a Ruby on Rails developer. Nice to see such cooperation between two similar open source products.
- Ergomane 14y ago
  It's probably out of spite. At an OSS project I worked on previously they'd always hack into competing projects when they trashed the project's security. If you live in a glass house, don't go around throwing stones.
  - gojomo 14y ago
    If throwing stones makes the targets do free vulnerability probing in return, why not? :)
    - ubernostrum 14y ago
      Or if there's actually a history of web frameworks doing behind-the-scenes coordination and watching each other's backs... oh wait, that's not as good a gossip narrative. Never mind.
  - jacobian 14y ago
    That's 100% completely wrong. We've worked with Rails' security team in the past to coordinate releases fixing similar issues, and they've helped us out with discovering and analyzing issues of our own. They're a great group of people and I've got nothing but good things to say about our work together. Yet another reason why open source is fantastic: friendly competition can actually be friendly. It rocks.
    - tenderlove 14y ago
      We've hacked in to your hearts. ;-) Django folks I've worked with were extremely smart, helpful, and kind. Likewise I only have great things to say. <3<3<3<3<3<3
Ergomane 14y ago
Is the XML expansion issue truly just a DOS issue, or is it possible for attackers to get feedback (either directly or on subsequent requests) on the XML parse result and thus read local files via a SYSTEM entity?
- _carljm 14y ago
  AFAIK the XML entity expansion attacks are DoS-only, but the other fixed vulnerability (external entities) may be usable in some cases to gain information about local files (again, presuming Django's XML model deserializer is exposed to untrusted input, which it is not by default and should not be). I'm working on updating the announcement and release notes to characterize that more accurately.
oellegaard 14y ago
For a second I got scared. Then I saw the fixes and realized that I don't have to panic-update. It is great that the issues are fixed but none of them seem very dangerous. DoS can always be done and I doubt many people use the XML serializer/admin log. Not sure about how many people use get_host(), but I imagine its not a lot of people.
- daenz 14y ago
  > DoS can always be done Assume you're not talking about DDoS, how?
  - mpyne 14y ago
    Piss off the wrong person, normally...
  - StavrosK 14y ago
    I've always wondered: What stops someone from uploading a 10 GB file using Django's upload forms? The file could even be very small when gzipped, it sounds like a reasonable and easy DoS attack.
endtwist 14y ago
It seems particularly crazy to me that many people find out about security releases (or any releases) like this. What happens when one doesn't make the front page of HN? Apologies for the shameless plug but at BundleScout we've been working on a tool to notify you when things like this happen[1]. It's not perfect, but it's a step up from this I'd hope. [1] https://bundlescout.com/search?q=django https://bundlescout.com/search?q=django
- archivator 14y ago
  Like what exactly? Anyone using Django in a production environment, should be following django-announce anyway - https://groups.google.com/forum/?fromgroups#!forum/django-announce https://groups.google.com/forum/?fromgroups#!forum/django-an...
- bconway 14y ago
  I imagine most people sign up for the announcement and/or security mailing lists of the products that are critical to their infrastructure.
- glfomfn 14y ago
  Your tool doesn't currently show the last security update, according to your website last update was 2 months ago. Django wise, there is the Google group which you can be follow for all updates , you can also subscribe to the RSS feed of django's weblog. Your tool seems interesting, i like the idea of being able to keep a list of all the software i use in a single place and get notified when a new update comes out(had a similar idea myself), however i would need some kind of reassurance that such an application is reliable and wont let me in the dark for some important update.
  - endtwist 14y ago
    Typically, the updater runs about once a day. If you take another look, it will show the latest security update :) We're working very, very hard to guarantee that no updates go missed and ensure that you receive a notification within 24 hours of any update going out. And while, yes, you can watch the RSS feed or Google group, do you really want to do that for Django and the other 29 libraries you use?
Negitivefrags 14y ago
> Django's serialization framework was vulnerable to denial of service attacks via XML entity expansion and external references Ah yes, the billion laughs. http://en.wikipedia.org/wiki/Billion_laughs http://en.wikipedia.org/wiki/Billion_laughs
- tptacek 14y ago
  Django has the right response to this issue: disable entity handling altogether. Last I checked, this was not the Rails response; you can pass doctype declarations in with XML in POST requests, and they're honored (this was clearly the case during YAML-debacle #1, because we took advantage of it, but I think it remains the case now). There is no good reason that core XML handling in frameworks should be dealing with dynamically defined entities at all.
  - steveklabnik 14y ago
    Look what just came across my radar a few minutes ago: https://github.com/rails/rails/pull/9328 https://github.com/rails/rails/pull/9328
    - nolok 14y ago
      Not the same thing, he's talking about how the xml are parsed, not whether they are parsed or not. If you install this new gem in RoR, the xml parsing would still do what tptacek is talking about (processing external entities), which is something that should be off by default because you almost never actually want it.
      - steveklabnik 14y ago
        I understand that, but it's the default that's important here. If this gets merged, Rails will no longer be automatically parsing XML from parameters by default. Yes, the gem that's extracted could also be checked over for things like the processing of external entities. I'm not familiar with that part of the code, so I can't tell you what it does or does not do.

128 points by hrayr 14y ago

jtchang 14y ago

Just upgraded...nothing really broke for me so looks good. Nice to see lots of back porting of the security fixes.

naiquevin 14y ago
I too upgraded and everything went smooth except got a "Bad magic number" error[1] while running south migrations. The fix is to delete all .pyc files (even those inside the virtualenv) [1]: http://stackoverflow.com/questions/514371/whats-the-bad-magic-number-error http://stackoverflow.com/questions/514371/whats-the-bad-magi...

gojomo 14y ago

I don't see the usual strong admonition to upgrade ASAP. (For example, the December 10 updates said, "All users are encouraged to upgrade Django immediately." This bulletin does not.) From a quick skim of the 4 fixes, perhaps not all Django sites may be at risk. For example, if they are: already checking the 'Host' header or not using it; not using Formsets; not using multiple tiers of admin users; not using Django's XML (de-)serialization. But, I'm least confident of that last one. Do all Django installs use Django's XML deserialization for something internal/everpresent? Or is this just a risk for users whose apps explicitly do extra XML operations?

jacobian 14y ago
These aren't "drop everything, take the site down, upgrade now" issues, so yeah we'd like to save the tone for that sort of thing. ... but seriously, please do upgrade as soon as possible! There's really no such thing as a "minor" security issue when it's 2am and you're being woken 'cause the site's down.
pindi 14y ago
No, Django's XML deserialization is not used automatically. It is only used for mass importing objects to the database, which most sites would allow only admin users to do.
danielweber 14y ago
Two of the issues are DoS issues, which aren't "drop everything, upgrade now." If you don't trust your admins, the fourth issue is very important, but lots of places put complete trust in them. The first issue is more about not becoming a vector for a phishing attack, AIUI.

deleted 14y ago

[deleted]

wittekm 14y ago

Interesting that one of the bugs was reported by a Ruby on Rails developer. Nice to see such cooperation between two similar open source products.

Ergomane 14y ago
It's probably out of spite. At an OSS project I worked on previously they'd always hack into competing projects when they trashed the project's security. If you live in a glass house, don't go around throwing stones.
- gojomo 14y ago
  If throwing stones makes the targets do free vulnerability probing in return, why not? :)
  - ubernostrum 14y ago
    Or if there's actually a history of web frameworks doing behind-the-scenes coordination and watching each other's backs... oh wait, that's not as good a gossip narrative. Never mind.
- jacobian 14y ago
  That's 100% completely wrong. We've worked with Rails' security team in the past to coordinate releases fixing similar issues, and they've helped us out with discovering and analyzing issues of our own. They're a great group of people and I've got nothing but good things to say about our work together. Yet another reason why open source is fantastic: friendly competition can actually be friendly. It rocks.
  - tenderlove 14y ago
    We've hacked in to your hearts. ;-) Django folks I've worked with were extremely smart, helpful, and kind. Likewise I only have great things to say. <3<3<3<3<3<3

Ergomane 14y ago

Is the XML expansion issue truly just a DOS issue, or is it possible for attackers to get feedback (either directly or on subsequent requests) on the XML parse result and thus read local files via a SYSTEM entity?

_carljm 14y ago
AFAIK the XML entity expansion attacks are DoS-only, but the other fixed vulnerability (external entities) may be usable in some cases to gain information about local files (again, presuming Django's XML model deserializer is exposed to untrusted input, which it is not by default and should not be). I'm working on updating the announcement and release notes to characterize that more accurately.

oellegaard 14y ago

For a second I got scared. Then I saw the fixes and realized that I don't have to panic-update. It is great that the issues are fixed but none of them seem very dangerous. DoS can always be done and I doubt many people use the XML serializer/admin log. Not sure about how many people use get_host(), but I imagine its not a lot of people.

daenz 14y ago
> DoS can always be done Assume you're not talking about DDoS, how?
- mpyne 14y ago
  Piss off the wrong person, normally...
- StavrosK 14y ago
  I've always wondered: What stops someone from uploading a 10 GB file using Django's upload forms? The file could even be very small when gzipped, it sounds like a reasonable and easy DoS attack.

endtwist 14y ago

It seems particularly crazy to me that many people find out about security releases (or any releases) like this. What happens when one doesn't make the front page of HN? Apologies for the shameless plug but at BundleScout we've been working on a tool to notify you when things like this happen[1]. It's not perfect, but it's a step up from this I'd hope. [1] https://bundlescout.com/search?q=django https://bundlescout.com/search?q=django

archivator 14y ago
Like what exactly? Anyone using Django in a production environment, should be following django-announce anyway - https://groups.google.com/forum/?fromgroups#!forum/django-announce https://groups.google.com/forum/?fromgroups#!forum/django-an...
bconway 14y ago
I imagine most people sign up for the announcement and/or security mailing lists of the products that are critical to their infrastructure.
glfomfn 14y ago
Your tool doesn't currently show the last security update, according to your website last update was 2 months ago. Django wise, there is the Google group which you can be follow for all updates , you can also subscribe to the RSS feed of django's weblog. Your tool seems interesting, i like the idea of being able to keep a list of all the software i use in a single place and get notified when a new update comes out(had a similar idea myself), however i would need some kind of reassurance that such an application is reliable and wont let me in the dark for some important update.
- endtwist 14y ago
  Typically, the updater runs about once a day. If you take another look, it will show the latest security update :) We're working very, very hard to guarantee that no updates go missed and ensure that you receive a notification within 24 hours of any update going out. And while, yes, you can watch the RSS feed or Google group, do you really want to do that for Django and the other 29 libraries you use?

Negitivefrags 14y ago

> Django's serialization framework was vulnerable to denial of service attacks via XML entity expansion and external references Ah yes, the billion laughs. http://en.wikipedia.org/wiki/Billion_laughs http://en.wikipedia.org/wiki/Billion_laughs

tptacek 14y ago
Django has the right response to this issue: disable entity handling altogether. Last I checked, this was not the Rails response; you can pass doctype declarations in with XML in POST requests, and they're honored (this was clearly the case during YAML-debacle #1, because we took advantage of it, but I think it remains the case now). There is no good reason that core XML handling in frameworks should be dealing with dynamically defined entities at all.
- steveklabnik 14y ago
  Look what just came across my radar a few minutes ago: https://github.com/rails/rails/pull/9328 https://github.com/rails/rails/pull/9328
  - nolok 14y ago
    Not the same thing, he's talking about how the xml are parsed, not whether they are parsed or not. If you install this new gem in RoR, the xml parsing would still do what tptacek is talking about (processing external entities), which is something that should be off by default because you almost never actually want it.
    - steveklabnik 14y ago
      I understand that, but it's the default that's important here. If this gets merged, Rails will no longer be automatically parsing XML from parameters by default. Yes, the gem that's extracted could also be checked over for things like the processing of external entities. I'm not familiar with that part of the code, so I can't tell you what it does or does not do.