Rails XML Parsing Vulnerability affecting JRuby users | Hacker News Reader

Rails XML Parsing Vulnerability affecting JRuby users

groups.google.com

27 pointscheald13 comments

Open articleView on HN

Three vulnerabilities announced at the same time...

* [CVE-2013-1855] XSS vulnerability in sanitize_css in Action Pack [1]

* [CVE-2013-1856] XML Parsing Vulnerability affecting JRuby users [2]

* [CVE-2013-1857] XSS Vulnerability in the `sanitize` helper of Ruby on Rails [3]

Two of these affect all Rails versions, not just JRuby, so are more serious.

[1] https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

[2] https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

[3] https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

I was gonna post 'em all, but my second one got auto-dead'd. Probably tripped the spam filter.

Is it possible to update the title of this post to remove the "affecting JRuby users" portion? The current title will give non-JRuby users a false sense of security.

This vulnerability is only applicable to JRuby users who use the JDOM parser. JDOM is not usable on non-JRuby platforms.

CVE-2013-1855 & CVE-2013-1857 are applicable to ALL Ruby users, not just JRuby.

Oh, I read you now. Since the link goes to just the JRuby-related announcement, I'm going to leave it in place for now, but please go ahead and submit the other two (especially the sanitize() one) - the spam filter seems to be upset at me. :)

There's supposed to be 4, but google groups seems to be swallowing my announcement emails. :'(

Here is the fourth one:

https://groups.google.com/forum/#!topic/ruby-security-ann/o0...

From the provided patch: the HTML sanitizer vulnerability appears to be a bug separate from the past YAML deserialization security problems (and somewhat less severe).

The sole change seems to be in the regex that was used to match the protocol separator (i.e. the colon). The change is from this:

      /:|(&#0*58)|(&#x70)|(%|&#37;)3A/

to this:

      /:|(&#0*58)|(&#x70)|(&#x0*3a)|(%|&#37;)3A/i

Presumably the previous regex allowed an attacker to insert a variation of "javascript:foo()" and get past a HTML sanitize call.

So this seems similar to the mess Rails had recently, which is kind of surprising because one would think it would prompt people to take a suspicious glance at their own XML parsing bits sooner rather than later.

Rails and security. Again. Sigh.

If you're going to work in software, you had better get used to it. The difference between software with a CVE rap sheet and software without is that you know about the vulns in the software with the CVE rap sheet.

You know about some of them, anyway.

Fair point. The larger picture is that while the number of CVEs certainly matters, what matters most is that the maintainers of the software maintain a record of quick turn around on patches and a welcoming attitude toward security researchers.

IMO, Rails has done a better job of this recently, and that makes me really happy.

Reply on news.ycombinator.com