Page MenuHomePhabricator

Null byte in old versions of Replace Text may cause arbitrary execution
Closed, DeclinedPublic


OK, bear with me, because I haven't actually tested this.

If a null byte is passed as part of the target text, older versions of PHP/PRCE interpret that as the end of the string, which means that the user can pass a eval flag to execute the replacement text. The best explanation of it I've seen is here:

That null bug was fixed in PHP 5.4.7, which means that Mediawiki version ≥1.24 is immune as it requires 5.5.9. Any previous branches, like REL1_23, however, may have an arbitrary execution.

I don't have an old copy of PHP and Mediawiki around to test, but you are still distributing a REL1_23 branch, so I thought I should mention it.

Event Timeline

labster created this task.Aug 7 2016, 1:10 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 7 2016, 1:10 AM
Legoktm added a subscriber: Legoktm.Aug 7 2016, 3:57 AM

That null bug was fixed in PHP 5.4.7, which means that Mediawiki version ≥1.24 is immune as it requires 5.5.9

MediaWiki only started requiring 5.5.9+ in 1.27. 1.26, and 1.25 work with 5.3.3+.


If you are unable to upgrade to PHP 5.5.9, then you can use MediaWiki 1.23.13, which requires PHP version 5.3.2 or later is a little misleading. LTS release I guess.

@Yaron_Koren, @Nikerabbit, what are your thoughts on this issue?

Bawolff added a subscriber: Bawolff.EditedAug 23 2016, 8:24 PM

I'm concerned about SearchHighlighter::highlightText in core

Bawolff claimed this task.Aug 23 2016, 8:54 PM

It should be also noted, that even if you have a high enough version of php not to be vulnerable, anything that allows an arbitrary regex pattern is an easy DOS attack.

Bawolff - are you saying you're concerned about a vulnerability in core MediaWiki? If so, you should open a separate ticket about that - this one is specific to the Replace Text extension.

Bawolff triaged this task as High priority.Sep 20 2016, 8:49 PM

In terms of the DOS attack @Bawolff mentioned, maybe ini_set on some PCRE options would be useful?

Replace text actually isn't vulnerable to this bug, since it gets its regex via $this->getRequest()->getText(), which normalizes unicode, thus removing any null bytes from the input.

Maybe we should also have an explicit check for null bytes, I'm not sure.

Bawolff closed this task as Declined.May 10 2019, 10:02 PM

This is old enough now to no longer be relevant.

Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)".May 10 2019, 10:03 PM