Last modified: 2014-02-07 20:03:03 UTC
Created attachment 14358 [details] 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 ---
Created attachment 14359 [details] 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'
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.
FYI, This has been assigned CVE-2014-1610.
Created attachment 14361 [details] Escape shell arguments Escape as well as validate, per usual coding style.
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 [details] Clean up related escaping issues Something like this untested patch.
Created attachment 14383 [details] 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.
Created attachment 14384 [details] PDF Handler - wmf11
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 [details] Core REL1_22 Backport for 1_22
Adding early access partners. We are planning to release these patches as part of 1.22.2 tomorrow (Tuesday Jan 28th).
Created attachment 14392 [details] Core REL1_21
Created attachment 14393 [details] Core REL1_19
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 [details] 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
