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.

Look what just came across my radar a few minutes ago: https://github.com/rails/rails/pull/9328

Argh. Why not just neutralize XML to make it safer, rather than kicking the can to the developers who need it?

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

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.

> 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?

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.

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.

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.

I don't have any opinions on it, I just linked to a pull request.

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.

> 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.

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.