Last modified: 2013-03-25 15:22:33 UTC
If I post a long external link into wiki text, like: http://maps.google.com.tw/maps?f=q&source=s_q&hl=zh-TW&geocode=&q=11002+%E8%87%BA%E5%8C%97%E5%B8%82%E5%BF%A0%E5%AD%9D%E6%9D%B1%E8%B7%AF%E5%9B%9B%E6%AE%B5547%E8%99%9F&aq=&sll=23.352343,120.970459&sspn=9.803923,16.907959&brcurrent=3,0x3442abadec7543e7:0x5dbcdd8252aeabe7,0,0x3442ac6b61dbbd9d:0xc0c243da98cba64b&ie=UTF8&hq=&hnear=110%E5%8F%B0%E5%8C%97%E4%BF%A1%E7%BE%A9%E5%8D%80%E5%BF%A0%E5%AD%9D%E6%9D%B1%E8%B7%AF%E5%9B%9B%E6%AE%B5547%E8%99%9F&z=17 WikiMedia causes php to crash everytime! This is my Windows Event Log: > Faulting application name: httpd.exe, version: 2.2.17.0, time stamp: 0x4cbbe9e8 > Faulting module name: php5ts.dll, version: 5.3.6.0, time stamp: 0x4d81e545 > Exception code: 0xc00000fd > Fault offset: 0x00188f63 > Faulting process id: 0x11a8 > Faulting application start time: 0x01cc1dd12482a372 > Faulting application path: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin\httpd.exe > Faulting module path: C:\Program Files (x86)\PHP\php5ts.dll > Report Id: e4932ef5-89c4-11e0-9e1a-00237db9fac6 And in the meantime, my Apache httpd error.log show up either message: > [Sun May 29 15:25:57 2011] [notice] Parent: child process exited with status 255 -- Restarting. > [Sun May 29 15:28:18 2011] [notice] Parent: child process exited with status 3221225725 -- Restarting.
Confirmed on my Win7/x64 box with PHP 5.3.5 (XAMPP).
So this is a PHP bug? What can we do about it?
My another Windows Server 2008 R2 with PHP 5.3.2 and older version of MediaWiki (r70253) is OK for long external link.
We certainly can do something about this, since we introduced it in r84022.
Is 313 characters a hard limit, or does it depend on the resources available to PHP? This rev should probably be reverted until it's fixed, as it's a trivial DOS vector.
The magic number "313" is what I observed from my Windows Server 2008 R2 + PHP 5.3.6 + MW 1.19alpha (r89086), Maybe Max Semenik can prove or disprove this on his environment :)
Thanks for your quick response in r89088. Should we add a test case for long external link string to prevent this issue from regression?
(In reply to comment #7) > Should we add a test case for long external link string to prevent this issue > from regression? I'm not sure a test case would help since this appears to be a problem that should be reported to PHP developers. In fact, I wonder if this might be caused by XAMMP instead of PHP since I'm running PHP 5.3.5-1ubuntu7.2 at MW r89000 and it works. Also, trying with PHP 5.3.6 under Fedora with MW 89000 shows no problems. Will now try WAMP and XAMP.
I don't think we can add a test case for it. It will probably pass in command line. These errors depend on the stack size of httpd.exe. bugs.php.net would tell you to run link.exe to modify its header or to decrease pcre.backtrack_limit and pcre.recursion_limit. Mark, to make that fail in Linux you would need to restrict the stack size with ulimit.
Using (?:[^\]\[<>"\x00-\x20\x7F]+|\[\])+) instead of (?:[^\]\[<>"\x00-\x20\x7F]|\[\])+) is probably cheaper. Can you test?
The point where it errors for me with a 64bit php (and a test script) is with ulimit -s515 at doMagicLinks (the preg_split passes), where as with the old regex, it worked up to ulimit -s42. With the modification proposed at comment 10, it runs again until -s44. Note that these tests are specific to the provided url testcase, and that with the same borderline settings, it may sometimes works and sometimes fails.
That's still pretty close to recovering the original performance (-s isn't logarithmic or anything, is it?)
ulimit -s sets the stack size in kb. The problem was in the regex which we made mucho more complex, and is itself included into another big regex.
Indeed; but you seem to have found an optimisation which produces the same functionality for ony a 5% memory footprint penalty, as opposed to the 1125% penalty in the original version. Is that good enough performance to put it back in? Does this mean it's possible to crash *any* server with a long enough URL?
Does not occur on IIS with PHP 5.3.4 (cgi-fcgi).
It is unlikely to occur with cgi/fastcgi, since in that case it uses the stack set in php binary.
