Last modified: 2013-02-02 08:50:06 UTC
Reported by Kevin Israel. Roan is adding a fix for this now. >>> I found MediaWiki 1.20 and newer allow arbitrary code to be injected into ''every'' page (even Special:ChangeEmail, Special:ChangePassword, and Special:Preferences) through the "editfont" option. Although not an immediate security problem, it has the implication that trojanized user scripts and other malware could potentially a) store malicious JavaScript code where hardly anyone would notice it; and b) bypass the OutputPage::disallowUserJs() check. Previously, all preference changes had to be made through Special:Preferences, which performs some validation (at least for the "editfont" option). However, the API "options" module does not validate preference values, and neither does the ResourceLoader code that generates a corresponding CSS rule. </style><script src="/w/index.php?title=User:Evil/script.js&action=raw"></script><style>*{ Because users cannot see each other's preferences, such code injection might allow long-term account compromise to remain undetected for a while. Also, because style elements are added in the head section of the HTML code, at the top of the page, such injection can be used to create more convincing phishing attacks, especially when it is used to inject code into the special pages mentioned above.
*** Bug 42203 has been marked as a duplicate of this bug. ***
Created attachment 11382 [details] Validate editfont in RL module Perform basic validation of 'editfont' in the user.cssprefs module. This whitelists the characters needed to support the current options for editfont (a-z and -) as well as [A-Z0-9_] for future use, and [, ] for specifying multiple font families in the future. After briefly talking to Chris I chose not to include " (needed for font names with spaces in them, but scary from a validation perspective).
Created attachment 11383 [details] Perform validation in action=options API The action=options API module wasn't performing any validation whatsoever, so validate preference values before storing them.
Patches look good to me. I'll have Reedy push these to the cluster on Monday (at least the ResourceLoaderUserCSSPrefsModule.php patch), unless anyone sees a problem with them.
Can you add here a pointer to the change, for future reference?
For the resource loader change: * master: Gerrit change #36084 (change I5c12aa9a) (commit 8e57acf21152a688dcb147e6e2bf5c97ef6860af) * REL1_20: Gerrit change #36073 (change I5c12aa9a) (commit 6790a0ce962fb41dc03e06b133f48443cde3c0e0) For the API module change: * master: Gerrit change #36085 (change I98df55f2) (commit fe45ba87528d855b4f12785016280451bd7893cf) * REL1_20: Gerrit change #36132 (change I3da32a21) (commit 385342c6aea95ae6c7f8f0d994382a7c17037030)
Note the change fixing this bug caused bug 42638 and bug 42639.
This fix also caused bug 44359 and some other extension bugs. Next time please advertize more widely before turning off a major API feature. Thanks!
