> There is a DoS vulnerability in the REXML library used by Rails to > parse incoming XML requests.
To be clear: This is a Rails issue, not a general REXML issue?
The post suggests that Rails uses a different REXML library than what ships with the standard Ruby distro, and mentions no other Ruby framework (Web or otherwise).
>> There is a DoS vulnerability in the REXML library used by Rails to >> parse incoming XML requests.
> To be clear: This is a Rails issue, not a general REXML issue?
> The post suggests that Rails uses a different REXML library than what ships > with the standard Ruby distro, and mentions no other Ruby framework (Web or > otherwise).
But the versions it lists affected are Ruby versions, not Rails versions. Since REXML is part of the standard library, and particular Ruby (not Rails) versions are affected, I think the part of the description that focuses on the risk to Rails is most likely misguided, and that its a general REXML, not Rails, problem.
Testing the example file in irb on Ruby 1.8.6 on WinXP, without loading any rails-related libraries, it seems to grab all the processor resources it can and just hang (this occurs when you access the only text node of the root element, not on the initial parse, because until you do that, REXML doesn't try to expand the entities), so I think tha clinches that its Ruby, not Rails.
Want to name someone evil? I'd vote this is an issue of XML itself. REXML is just doing what it is asked to do. The problem is, it's (by design) unclear how much resources are required to parse an XML document, until we actually parse that document.
So, in fact this problem can happen without REXML, or even without Ruby. If you're using other XML parser, be sure that engine can handle this issue correctly.
>>> There is a DoS vulnerability in the REXML library used by Rails to >>> parse incoming XML requests.
>> To be clear: This is a Rails issue, not a general REXML issue?
>> The post suggests that Rails uses a different REXML library than what ships >> with the standard Ruby distro, and mentions no other Ruby framework (Web or >> otherwise).
> But the versions it lists affected are Ruby versions, not Rails > versions. Since REXML is part of the standard library, and particular > Ruby (not Rails) versions are affected, I think the part of the > description that focuses on the risk to Rails is most likely > misguided, and that its a general REXML, not Rails, problem.
> Testing the example file in irb on Ruby 1.8.6 on WinXP, without > loading any rails-related libraries, it seems to grab all the > processor resources it can and just hang (this occurs when you access > the only text node of the root element, not on the initial parse, > because until you do that, REXML doesn't try to expand the entities), > so I think tha clinches that its Ruby, not Rails.
>>> There is a DoS vulnerability in the REXML library used by Rails to >>> parse incoming XML requests. >> To be clear: This is a Rails issue, not a general REXML issue?
>> The post suggests that Rails uses a different REXML library than what ships >> with the standard Ruby distro, and mentions no other Ruby framework (Web or >> otherwise).
> But the versions it lists affected are Ruby versions, not Rails > versions.
The original post said referred to "the REXML library used by Rails", not the REXML library included with Ruby's standard distro.
And were this an issue with a standard Ruby lib, and not a customized Rails version, I would have expected an actual patch for the REXML source so that all code using REXML is patched.
> Since REXML is part of the standard library, and particular > Ruby (not Rails) versions are affected, I think the part of the > description that focuses on the risk to Rails is most likely > misguided, and that its a general REXML, not Rails, problem.
> Testing the example file in irb on Ruby 1.8.6 on WinXP, without > loading any rails-related libraries, it seems to grab all the > processor resources it can and just hang (this occurs when you access > the only text node of the root element, not on the initial parse, > because until you do that, REXML doesn't try to expand the entities), > so I think tha clinches that its Ruby, not Rails.
Then the original post is misleading in emphasizing Rails.
Lots of people use REXML on the Web outside of Rails, so the effect on Rails is incidental to the real problem and should have been omitted for clarity.
James Britt wrote: > Then the original post is misleading in emphasizing Rails.
> Lots of people use REXML on the Web outside of Rails, so the effect on > Rails is incidental to the real problem and should have been omitted > for clarity.
Incidental yes, but that doesn't mean Rails users must be ignored. Perhaps web-admins should not omit Rails workarounds, but also add a note that non-Rails apps can suffer this issue.
Urabe Shyouhei wrote: > James Britt wrote: >> Then the original post is misleading in emphasizing Rails.
>> Lots of people use REXML on the Web outside of Rails, so the effect on >> Rails is incidental to the real problem and should have been omitted >> for clarity.
> Incidental yes, but that doesn't mean Rails users must be ignored. > Perhaps web-admins should not omit Rails workarounds, but also add a > note that non-Rails apps can suffer this issue.
Not ignored, but the report should focus on the risk to any application using Ruby's standard REXML library, including, but not limited to, Web applications, such as as Merb, Ramaze, Rails, and others that may be accepting arbitrary XML from outside source.
On Sat, Aug 23, 2008 at 7:37 PM, Urabe Shyouhei <shyou...@ruby-lang.org> wrote: > James Britt wrote: >> Then the original post is misleading in emphasizing Rails.
>> Lots of people use REXML on the Web outside of Rails, so the effect on >> Rails is incidental to the real problem and should have been omitted >> for clarity.
> Incidental yes, but that doesn't mean Rails users must be ignored. > Perhaps web-admins should not omit Rails workarounds, but also add a > note that non-Rails apps can suffer this issue.
But really, the case is "Any Ruby code parsing user passed XML", which is in no way limited to Rails. It's reasonable to say "Hey Rails kids, this means you!", but I think it's a little misleading to pass it off as a Rails bug with a monkeypatch rather than a patch against Ruby itself.
On Sat, Aug 23, 2008 at 4:37 PM, Urabe Shyouhei <shyou...@ruby-lang.org> wrote: > James Britt wrote: >> Then the original post is misleading in emphasizing Rails.
>> Lots of people use REXML on the Web outside of Rails, so the effect on >> Rails is incidental to the real problem and should have been omitted >> for clarity.
> Incidental yes, but that doesn't mean Rails users must be ignored. > Perhaps web-admins should not omit Rails workarounds, but also add a > note that non-Rails apps can suffer this issue.
The notice on the ruby-lang.org includes the general workaround and the Rails-specific instructions (the monkeypatch is general, there is a special mechanism for guaranteeing it is included given for Rails.) The problem with the notice is that it the beginning part that announces the problem makes it sound like it is in a Rails component, when it is in the Ruby Standard Library. Instead of this:
---[begin] There is a DoS vulnerability in the REXML library used by Rails to parse incoming XML requests. A so-called "XML entity explosion" attack technique can be used for remotely bringing down (disabling) any application which parses user-provided XML. Most Rails applications will be vulnerable to this attack. ---[end]
It should say something like this:
---[begin] There is a DoS vulnerability in the REXML library included in the Ruby Standard Library. A so-called "XML entity explosion" attack technique can be used for remotely bringing down (disabling) any application which parses user-provided XML using REXML. ---[end]
Any specific notes about systems that rely on REXML (including Rails) should have followed that accurate description of the nature and applicability of the problem. (I also question whether its true that "Most Rails applications will be vulnerable to this attack", is it really true that the majority of Rails apps consume XML from untrusted sources?
<gregory.t.br...@gmail.com> wrote: > On Sat, Aug 23, 2008 at 7:37 PM, Urabe Shyouhei <shyou...@ruby-lang.org> wrote: >> James Britt wrote: >>> Then the original post is misleading in emphasizing Rails.
>>> Lots of people use REXML on the Web outside of Rails, so the effect on >>> Rails is incidental to the real problem and should have been omitted >>> for clarity.
>> Incidental yes, but that doesn't mean Rails users must be ignored. >> Perhaps web-admins should not omit Rails workarounds, but also add a >> note that non-Rails apps can suffer this issue.
> But really, the case is "Any Ruby code parsing user passed XML", which > is in no way limited to Rails. > It's reasonable to say "Hey Rails kids, this means you!", but I think > it's a little misleading to pass it off as a Rails bug with a > monkeypatch rather than a patch against Ruby itself.
I don't think the monkeypatch has anything to do with Rails vs. Ruby, since there are general instructions for the monkeypatch followed by instructions on how to include it in a Rails app.
On Sat, Aug 23, 2008 at 8:03 PM, Christopher Dicely <cmdic...@gmail.com> wrote: > I don't think the monkeypatch has anything to do with Rails vs. Ruby, > since there are general instructions for the monkeypatch followed by > instructions on how to include it in a Rails app.
It has everything to do with Ruby vs. Rails.
If we are talking about a vulnerability in standard Ruby, we should be able to patch standard Ruby and be done with it, not be required to use some hackish monkeypatch in every application we write. Ruby core does of course, maintain Ruby's standard library (or so we hope.)
"Christopher Dicely" <cmdic...@gmail.com> wrote: > ---[begin] > There is a DoS vulnerability in theREXMLlibrary used by Rails to > parse incoming XML requests. A so-called "XML entity explosion" attack > technique can be used for remotely bringing down (disabling) any > application which parses user-provided XML. Most Rails applications > will be vulnerable to this attack. > ---[end]
> It should say something like this:
> ---[begin] > There is a DoS vulnerability in theREXMLlibrary included in the Ruby > Standard Library. A so-called "XML entity explosion" attack technique > can be used for remotely bringing down (disabling) any application > which parses user-provided XML usingREXML. > ---[end]
I admit that my announcement is misleading. It was based on the original report to secur...@rubyonrails.org.
What do you think of fixing it like this?
--- There is a DoS vulnerability in the REXML library included in the Ruby Standard Library. A so-called "XML entity explosion" attack technique can be used for remotely bringing down (disabling) any application which parses user-provided XML using REXML.
Most Rails applications will be vulnerable because Rails parses user-provided XML using REXML by default. ---
> Any specific notes about systems that rely onREXML(including Rails) > should have followed that accurate description of the nature and > applicability of the problem. (I also question whether its true that > "Most Rails applications will be vulnerable to this attack", is it > really true that the majority of Rails apps consume XML from untrusted > sources?
"Gregory Brown" <gregory.t.br...@gmail.com> wrote: > On Sat, Aug 23, 2008 at 8:03 PM, Christopher Dicely <cmdic...@gmail.com> wrote: > > I don't think the monkeypatch has anything to do with Rails vs. Ruby, > > since there are general instructions for the monkeypatch followed by > > instructions on how to include it in a Rails app.
> It has everything to do with Ruby vs. Rails.
> If we are talking about a vulnerability in standard Ruby, we should be > able to patch standard Ruby and be done with it, not be required to > use some hackish monkeypatch in every application we write. Ruby core > does of course, maintain Ruby's standard library (or so we hope.)
There are some considerations to apply this fix to the Ruby's standard library. This vulnerability (not Ruby specific but in general) had been known for a long time, so we decided to provide a monkey patch for a workaround.
We are discussing some considerations on ruby-dev ML, and I'll send a mail with details to ruby-core ML later.
On Thu, Aug 28, 2008 at 5:19 AM, Shugo Maeda <shugo.ma...@gmail.com> wrote: > Hi,
> "Gregory Brown" <gregory.t.br...@gmail.com> wrote: >> If we are talking about a vulnerability in standard Ruby, we should be >> able to patch standard Ruby and be done with it, not be required to >> use some hackish monkeypatch in every application we write. Ruby core >> does of course, maintain Ruby's standard library (or so we hope.)
> There are some considerations to apply this fix to the Ruby's standard > library. This vulnerability (not Ruby specific but in general) > had been known for a long time, so we decided to provide a monkey > patch > for a workaround.
> We are discussing some considerations on ruby-dev ML, and I'll send > a mail with details to ruby-core ML later.
Shugo Maeda <shugo.ma...@gmail.com> wrote: > What do you think of fixing it like this?
> --- > There is a DoS vulnerability in theREXMLlibrary included in the Ruby > Standard Library. A so-called "XML entity explosion" attack technique > can be used for remotely bringing down (disabling) any application > which parses user-provided XML usingREXML.
> Most Rails applications will be vulnerable because Rails parses > user-provided XML usingREXMLby default. > ---
