thumb.php must html-escape rel404 parameter in error message
Closed, ResolvedPublic

Description

Reported via security@.

A simple htmlspecialchars will do.

Original report from John Menerick:

To whom it may concern;

It appears there is a XSS vulnerability in MediaWiki's thumb.php source code. On line 35, the unvalidated or sanitized parameters are pulled from the client's request. As we see in the attached image, it flows through the code until the bottom of the data flow - wfthumberror, line 588 -> builtin_echo() .

The expected behavior is that the thumb.php's request handler properly sanitizes or validated the parameters before handing it to thumb.php. Or the output is properly sanitized before echo'd out to the client.

The impact isn’t clear to me due to the arcane workflow to get this code path to execute. The vector appears plausible. Hence this heads up.

Software) MediaWiki
Changelist) 57fb6ab46ca82305997c9956a6ec4887040e556e
Src) Github


Patch:

  • 1.25 - same as master ()
  • 1.24 - same as master ()
  • 1.23 - (minor updates)

Affected Versions: Since 1.21 (dfe02f371be76b236a0af9028f52584bef04a427 / a04d9cb7487773e102285de13b7092a2bc9b6821)
Type: xss

Krinkle created this task.Apr 28 2015, 5:45 AM
Krinkle claimed this task.
Krinkle changed the visibility from "Public (No Login Required)" to "Custom Policy".
Krinkle changed the edit policy from "All Users" to "Custom Policy".
Krinkle changed Security from None to Software security bug.
Krinkle added a subscriber: Krinkle.
Restricted Application added a project: Multimedia. · View Herald TranscriptApr 28 2015, 5:45 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Krinkle added a comment.EditedApr 28 2015, 5:48 AM

Recommended patch:

In a later commit, we should go through and mark all plain text ones as wfThumbErrorText(), and perhaps rename wfThumbError to wfThumbErrorHtml to be more explicit (keeping the old as deprecated back-compat wrapper).

Wow, lots of issues.

Confirmed the rel404 issue (officewiki was the only production wiki where I could get it to work):
curl -i 'https://office.wikimedia.org/w/thumb.php?f=1550_Evans_034.jpg&width=10&rel404=a<img+src="%23"+onerror=alert(1)/>' -H 'cookie: uls-previous-languages=%5B%22en%22%5D; officewikiUserID=288; officewikiUserName=Csteipp; forceHTTPS=true; officewikiSession=XXXXXXXXXXXXXXXXXXXXX'

ForeignAPI images also have an xss from the error on line 224:
https://en.wikipedia.org/w/thumb.php?f=File:River_1944.jpg%23asdf%3Cimg+src="%23"+onerror=alert(1)%3E&width=102

Probably the same issue on line 227, but I haven't figured out a way to get $img->exists() to be true but $img->getPath() to be false. Both should probably use wfThumbErrorText().

I think the error on 170 is safe (I can't find a way to create an image with scripting in the name which can then be deleted), but wouldn't hurt to use wfThumbErrorText() there too.

csteipp edited the task description. (Show Details)Apr 28 2015, 7:08 PM
csteipp added a project: Patch-For-Review.
csteipp triaged this task as "High" priority.
csteipp added a parent task: Restricted Task.May 4 2015, 10:10 PM
csteipp closed this task as "Resolved".
csteipp merged a task: Restricted Task.Aug 5 2015, 5:07 PM
csteipp added a subscriber: Ngocdh.Aug 5 2015, 8:25 PM
csteipp edited the task description. (Show Details)Aug 10 2015, 5:37 PM

csteipp edited the task description. (Show Details)Aug 10 2015, 5:39 PM
csteipp changed the visibility from "Custom Policy" to "Public (No Login Required)".Aug 10 2015, 10:00 PM
csteipp changed the edit policy from "Custom Policy" to "All Users".
csteipp changed Security from Software security bug to None.
Restricted Application added subscribers: Steinsplitter, Matanya. · View Herald TranscriptAug 10 2015, 10:00 PM

Change 230666 had a related patch set uploaded (by Chad):
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230666

Change 230670 had a related patch set uploaded (by Chad):
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230670

Change 230674 had a related patch set uploaded (by Chad):
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230674

Change 230674 merged by jenkins-bot:
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230674

Change 230670 merged by jenkins-bot:
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230670

Change 230666 merged by jenkins-bot:
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230666

Change 230775 had a related patch set uploaded (by Chad):
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230775

Change 230775 merged by jenkins-bot:
thumb.php: Escape $rel404 in error message

https://gerrit.wikimedia.org/r/230775

CVE-2015-6729 was assigned for the original issue, CVE-2015-6730 for further discoveries upon internal review.

Seems that this is an unknown xss vector:

/thumb.php?f=<body%20onload=alert%28document.domain%29>!!&archived=1

I reported this one 05/08/2015.

Seems that this is an unknown xss vector:

/thumb.php?f=<body%20onload=alert%28document.domain%29>!!&archived=1

I reported this one 05/08/2015.

No, I can't find a ticket about that.

It was reported to security@wikimedia.org

Ngocdh added a comment.Sep 1 2015, 2:47 AM

@csteipp ok. Just to make sure you see the difference: it's the same f parameter, but execution path is different. In my case, archived parameter has to be set.