As I understand it, Rails' string escaping would treat an invalid byte sequence (eg, 0xFF, 0x1C) as a single multi-byte code point, and thus not filter it, even though 0x1C (which is '<') should have been escaped.
The browser, however, would correctly treat 0xFF as an invalid initial byte, and then interpret the next character point, 0x1C ('<') independently.
So, you could pass arbitrary characters through Rails' string escape functions by prepending an initial invalid byte sequence, and thus cause the browser to interpret arbitrary JS/HTML.
Comments
I read through the code, but I don't really know Ruby that well, so I'm not 100% sure of what the exploit was.
Looking at the patch, it appears that their "check for UTF-8" function wasn't perfect. Is this correct? If so, how is this exploitable?
As I understand it, Rails' string escaping would treat an invalid byte sequence (eg, 0xFF, 0x1C) as a single multi-byte code point, and thus not filter it, even though 0x1C (which is '<') should have been escaped.
The browser, however, would correctly treat 0xFF as an invalid initial byte, and then interpret the next character point, 0x1C ('<') independently.
So, you could pass arbitrary characters through Rails' string escape functions by prepending an initial invalid byte sequence, and thus cause the browser to interpret arbitrary JS/HTML.
Thanks for the response. That does make sense.