

Rails XML Parsing Vulnerability affecting JRuby users - cheald
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/KZwsQbYsOiI

======
slashdotdash
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...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/4_QHo4BqnN8)

[2]
[https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/KZwsQbYsOiI)

[3]
[https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/zAAU7vGTPvI)

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

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

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

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

~~~
cheald
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. :)

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

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

------
static_typed
Rails and security. Again. Sigh.

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

~~~
lhc-
You know about some of them, anyway.

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

