Last modified: 2011-04-30 01:20:46 UTC
Kuriaki Takashi discovered an XSS vulnerability in MediaWiki 1.15.3. I've prepared a patch and it will be released shortly in 1.15.4 and 1.16beta3. The fix has been committed to trunk in r66990. I thought at the time of the 1.15.2 release that Internet Explorer did not implement CSS escape sequences. It turns out that it does, it's just that its implementation is so broken that none of my test cases worked on it. Once you actually know how it's implemented, you can construct CSS which executes arbitrary JS via expression(), but skips the filter due to parsing differences between MW and IE. In particular, Internet Explorer uses the platform-dependent iswspace() function to determine which characters to consume at the end of a hexadecimal escape sequence like "\72". It matches 21 space-like characters in Windows XP. This is incorrect, the CSS 2.0 specification clearly lists the (ASCII-only) characters which are to be considered whitespace. For example, using the notation <U+xxxx> for a Unicode character: MediaWiki 1.15.3 would consider a sequence like "u\72<U+3000>l(...)" to decode to the safe string "ur<U+3000>l(...)", whereas Internet Explorer would decode it to the unsafe string "url(...)". The fix I've committed involves normalising escape sequences to a form which can be processed accurately both by compliant browsers and by Internet Explorer. Unnecessary escape sequences are replaced with literal characters, and any remaining escape sequences are terminated by an ASCII space.
