4 ms·

> Django's serialization framework was vulnerable to denial of service attacks via XML entity expansion and external references Ah yes, the billion laughs. ht

> 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.
      - tptacek 14y ago
        I recommend familiarizing yourself with the code before developing strong opinions about it. I am familiar with what it looked like a month or so ago.
        steveklabnik 14y ago
        I don't have any opinions on it, I just linked to a pull request.
        tptacek 14y ago
        Sorry, I read an opinion from your comment immediately upthread, which is that you believe that simply not parsing XML is a reasonable step towards handling XML securely. I disagree with that opinion.
        steveklabnik 14y ago
        > you believe that simply not parsing XML is a reasonable step towards handling XML securely. Ahh, this may be the difference, sorry. I don't think that it's a reasonable step towards handling XML securely. I _do_ think it's a step towards not exposing people who don't use XML to attacks on their site via XML-parsing code paths. One of the worst parts of the recent security... situation was that people who didn't even support YAML or XML for their API were still vulnerable. It's these people this helps, not people who actually do use XML. I totally agree that this isn't useful to people who are actually using XML, except for my comments about quicker releases and fixes by detaching it from Rails.
  - tptacek 14y ago
    Argh. Why not just neutralize XML to make it safer, rather than kicking the can to the developers who need it?
    - steveklabnik 14y ago
      One of the reasons that things get extracted to gems is specifically so that people who use it can improve stuff without the whole process of contributing to Rails (and its release cycles) getting in the way. For example, ActiveResource[1]. Now that it's a gem, the people who use its features can actually take over the maintenance, and release versions independently from Rails proper. It's gotten a lot more contributions lately now that it's independent. 1: https://github.com/rails/activeresource https://github.com/rails/activeresource
      - tptacek 14y ago
        It is also a way of burying hair-on-fire security issues, and of encouraging plugin-style development for what is properly considered a piece of core functionality for Rails.
        steveklabnik 14y ago
        > It is also a way of burying hair-on-fire security issues, :/ I'm sorry you feel that way. I can only speak for myself, but I certainly don't want to bury any security issues, I want to fix them. > what is properly considered a piece of core functionality for Rails. Maybe automatically parsing XML parameters shouldn't be?
_carljm 14y ago
It's not just billion laughs, this fixes related but different entity-expansion attacks, as well as fetching of external resources (DTDs or entity definitions), which is a totally separate issue from 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.
    - tptacek 14y ago
      I recommend familiarizing yourself with the code before developing strong opinions about it. I am familiar with what it looked like a month or so ago.
      - steveklabnik 14y ago
        I don't have any opinions on it, I just linked to a pull request.
        tptacek 14y ago
        Sorry, I read an opinion from your comment immediately upthread, which is that you believe that simply not parsing XML is a reasonable step towards handling XML securely. I disagree with that opinion.
        steveklabnik 14y ago
        > you believe that simply not parsing XML is a reasonable step towards handling XML securely. Ahh, this may be the difference, sorry. I don't think that it's a reasonable step towards handling XML securely. I _do_ think it's a step towards not exposing people who don't use XML to attacks on their site via XML-parsing code paths. One of the worst parts of the recent security... situation was that people who didn't even support YAML or XML for their API were still vulnerable. It's these people this helps, not people who actually do use XML. I totally agree that this isn't useful to people who are actually using XML, except for my comments about quicker releases and fixes by detaching it from Rails.
- tptacek 14y ago
  Argh. Why not just neutralize XML to make it safer, rather than kicking the can to the developers who need it?
  - steveklabnik 14y ago
    One of the reasons that things get extracted to gems is specifically so that people who use it can improve stuff without the whole process of contributing to Rails (and its release cycles) getting in the way. For example, ActiveResource[1]. Now that it's a gem, the people who use its features can actually take over the maintenance, and release versions independently from Rails proper. It's gotten a lot more contributions lately now that it's independent. 1: https://github.com/rails/activeresource https://github.com/rails/activeresource
    - tptacek 14y ago
      It is also a way of burying hair-on-fire security issues, and of encouraging plugin-style development for what is properly considered a piece of core functionality for Rails.
      - steveklabnik 14y ago
        > It is also a way of burying hair-on-fire security issues, :/ I'm sorry you feel that way. I can only speak for myself, but I certainly don't want to bury any security issues, I want to fix them. > what is properly considered a piece of core functionality for Rails. Maybe automatically parsing XML parameters shouldn't be?

_carljm 14y ago

It's not just billion laughs, this fixes related but different entity-expansion attacks, as well as fetching of external resources (DTDs or entity definitions), which is a totally separate issue from billion laughs.