Page MenuHomePhabricator

Reported RCE in djvu thumbnailing
Closed, ResolvedPublic

Description

PoC from checkpoint

This was sent to security@mediawiki.org a few days ago, and I just got it last night. This morning I got the encrypted PoC from them. Obviously this is very serious.

Shell meta characters can be passed in the page parameter to the thumb.php.

This fix is trivial, I've just tested and confirmed it fixes the issue on my local dev. I'll upload a patch to the cluster and deploy it.

Chris,
The OTRS system wouldn't let me forward this to security@wikimedia.org since that used to be an OTRS address.

Ryan // User:Rjd0060

  • Forwarded message from Shahar Tal <shahartal@checkpoint.com> ---

From: Shahar Tal <shahartal@checkpoint.com>
To: "security@mediawiki.org" <security@mediawiki.org>
Cc: Netanel Rubin <netanelr@checkpoint.com>, Inbar Raz <inbarr@checkpoint.com>
Subject: Remote code execution via incorrectly sanitized parameter
Date: 2014-01-19 12:23:54

Hi, my name is Shahar Tal, I lead a security research team with Check Point's
Malware & Security Research group.

I am writing this to inform you of a critical RCE vulnerability that was
identified in core MediaWiki by Netanel Rubin - a researcher in my team.

The vulnerability enables unrestricted command injection via an incorrectly
sanitized parameter.
We have verified this vulnerability exists with default installations as long as a
certain (not uncommon) setting is enabled, as is on wikimedia.org (see attached
screenshot for verification).

Note that it is our policy to follow responsible disclosure etiquette, and while
we do eventually intend to make the vulnerability details public - we strongly
prefer it would be done in full coordination and only after a fix has been made
available.

We would like to submit the details privately to the responsible parties, as well
as suggest a fix, please contact me for further coordination.

Regards,

Shahar TalAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Check Point Software Technologies | * +972-77-775-8352 | M +972-545-888887 | *
shahartal@checkpoint.com<mailto:shahartal@checkpoint.com>

  • End forwarded message ---

Version: unspecified
Severity: critical

attachment mediawiki-rce-19-01-2014.pdf ignored as private

Details

Reference
bz60339

Related Objects

StatusSubtypeAssignedTask
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 2:55 AM
bzimport set Reference to bz60339.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 14359
intval the page parameter

Deployed onto the cluster, due to severity:

14:34 logmsgbot: csteipp synchronized php-1.23wmf10/includes/media 'bug60339'
14:33 logmsgbot: csteipp synchronized php-1.23wmf11/includes/media 'bug60339'

attachment bug60339.patch ignored as obsolete

Adding Shahar, the reporter.

Shahar, as I mentioned in email too, I'd like to confirm that we don't have similar issues elsewhere in our image handling, and then we'll release this as a security release in the next few business days.

shahartal wrote:

FYI, This has been assigned CVE-2014-1610.

Created attachment 14361
Escape shell arguments

Escape as well as validate, per usual coding style.

Attached:

Confirmed the vulnerability and tested the fix.

I checked all wfShellExec()/wfShellExecWithStderr() calls in includes/media:

BitmapHandler::transformImageMagick() should probably escape variables derived from string literals, such as $quality, on the basis that they may come from user input in the future. array_map('wfEscapeShellArg', array_merge(...)) could be used for argument assembly instead of string concatenation.

BitmapHandler::transformCustom() lacks escaping of $params['physicalHeight'] and $params['physicalWidth'].

BitmapHandler::rotate() depends on the "%" operator converting a string to a number, which seems a bit dodgy.

Created attachment 14364
Clean up related escaping issues

Something like this untested patch.

Attached:

content hidden as private in Bugzilla

Created attachment 14383
PDF Handler - wmf10

PDF Handler was also vulnerable after the last set of patches. These have been deployed on the Cluster. In wmf11, there was a change to remove the 2>&1, so there are versions of this patch for both wmf10 and wmf11.

Attached:

Created attachment 14384
PDF Handler - wmf11

Attached:

I've done some testing on Tim's patches, and deployed them on the cluster. Adding Bawolff in case he sees anything odd in file uploads or thumbnailing.

Created attachment 14389
Core REL1_22

Backport for 1_22

Attached:

Adding early access partners.

We are planning to release these patches as part of 1.22.2 tomorrow (Tuesday Jan 28th).

Created attachment 14392
Core REL1_21

Attached:

Created attachment 14393
Core REL1_19

Attached:

Change 110069 had a related patch set uploaded by CSteipp:
SECURITY: Sanitize shell command args

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

Change 110071 had a related patch set uploaded by CSteipp:
SECURITY: Sanitize shell command args

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

Change 110074 had a related patch set uploaded by CSteipp:
Sanitize shell command args

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

Change 110080 had a related patch set uploaded by CSteipp:
SECURITY: Escape all shell arguments

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

Change 110081 had a related patch set uploaded by CSteipp:
SECURITY: Escape all shell arguments

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

Change 110082 had a related patch set uploaded by CSteipp:
SECURITY: Escape all shell arguments

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

Change 110080 merged by jenkins-bot:
SECURITY: Escape all shell arguments

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

Change 110081 merged by jenkins-bot:
SECURITY: Escape all shell arguments

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

Change 110082 merged by jenkins-bot:
SECURITY: Escape all shell arguments

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

Clarification from the release announcement. Checkpoint did mention PdfHandler in their original PoC. Internal review found an additional vector not prevented by their proposed fix.

Change 110071 merged by jenkins-bot:
SECURITY: Sanitize shell command args

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

Change 110074 merged by jenkins-bot:
Sanitize shell command args

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

Change 110069 merged by jenkins-bot:
SECURITY: Sanitize shell command args

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

(Attachment 14358 from comment 0 is still private, is that intended?)

(In reply to comment #29)

(Attachment 14358 [details] from comment 0 is still private, is that
intended?)

It is. The attachment contains a working PoC for code execution on unpatched wikis, and I'd like to give our users some time to patch before making that part public. Additionally, Checkpoint dind't intend for that to be public, so it hasn't bean approved by their PR people and the researcher asked me to keep it private.

Once it seems like most wikis have patches, I'll at least make the exploit public, so we have a negative example that developers can see and prevent in the future.

Change 110215 had a related patch set uploaded by CSteipp:
SECURITY: Sanitize shell command args

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

Change 110215 merged by jenkins-bot:
SECURITY: Sanitize shell command args

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

Change 110423 had a related patch set uploaded by CSteipp:
SECURITY: Escape all shell arguments

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

Change 110423 merged by jenkins-bot:
SECURITY: Escape all shell arguments

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

Change 110424 had a related patch set uploaded by Reedy:
SECURITY: Escape all shell arguments

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

Change 110425 had a related patch set uploaded by Reedy:
SECURITY: Escape all shell arguments

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

Change 110424 merged by jenkins-bot:
SECURITY: Escape all shell arguments

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

Change 110425 merged by jenkins-bot:
SECURITY: Escape all shell arguments

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

Restricted Application added a subscriber: Luke081515. · View Herald Transcript