As you all know by now, the php2shell vulnerability was disclosed and is wreaking havoc all across the technology landscape wherever a PHP installation is involved as everybody is frantically patching their PHP installs to mitigate this vulnerability.
Since MapGuide bundles PHP, this vulnerability sadly also affects us as well and I feel obligated to at least post something about this.
So here's the current situation of this vulnerability in the context of MapGuide.
1. The next release
The upcoming 4.0.1 release already bundles PHP 8.3.36 that was released today to address this vulnerability, so no problems there. While that covers future releases, what about mitigating your current MapGuide installation?
Before we continue, I want to make it clear that the following mitigation procedure only applies to MapGuide Open Source 4.0. If you have an older version of MapGuide, its bundled PHP is out of the version range where a fix for php2shell is available, so unfortunately you are on your own.
2. Mitigating your MGOS 4.0 install (Windows)
The good news is that our PHP MapGuide API binding is binary compatible with newer releases of PHP 8.3, so in terms of mitigation. It is as simple as downloading a newer zip binary release of PHP 8.3, unzipping it to the Php directory of your web tier installation and then bringing across the php.ini and the MapGuide dll files from your older PHP install and you're good to go.
So firstly, stop the actively running web server (IIS or Apache httpd)
After that, you want the zip download of the VS16 Non Thread Safe build
After that, you want the zip download of the VS16 Non Thread Safe build
Then extract your downloaded zip file to the Php directory in your web tier installation directory.
Then you want to bring across the following files from PhpOld to Php, overwriting any files as necessary.
Then you want to bring across the following files from PhpOld to Php, overwriting any files as necessary.
ACE.dllGEOS.dlllib_json.dllMgFoundation.dllMgGeometry.dllMgHttpHandler.dllMgMapGuideCommon.dllMgMdfModel.dllMgMdfParser.dllMgPlatformBase.dllMgRenderers.dllMgStylization.dllMgWebApp.dllMgWebSupport.dllphp.inixerces-c_3_1mg.dllext/ACE.dllext/GEOS.dllext/lib_json.dllext/MgFoundation.dllext/MgGeometry.dllext/MgHttpHandler.dllext/MgMapGuideCommon.dllext/MgMdfModel.dllext/MgMdfParser.dllext/MgPlatformBase.dllext/MgRenderers.dllext/MgStylization.dllext/MgWebApp.dllext/MgWebSupport.dllext/php_MapGuideApi.dllext/xerces-c_3_1mg.dll
Then restart your respective web server and you're now using a bundled copy of PHP that is mitigated against php2shell.
3. Mitigating your MGOS 4.0 install (Linux)
The Linux story is a bit harder. We provide binaries for convenience, but binary patches are a different affair.
The main problem in terms of convenience is that PHP is only offered as a source tarball on Linux. MapGuide uses the same bundling strategy on Linux as it does on Windows, so it does not take advantage of any distro-supplied PHP.
As a result, you will have to build everything from source.
For the most painfree build experience, you can use the same docker-based build system that I use to produce binaries for Linux. If you check out the 4.0 svn branch, it will already have the updated PHP tarball.
For the most painfree build experience, you can use the same docker-based build system that I use to produce binaries for Linux. If you check out the 4.0 svn branch, it will already have the updated PHP tarball.
4. Thoughts on our PHP strategy going forward
This incident has really soured me on the idea of bundling PHP with MapGuide. I'm evaluating several options on reducing the blast damage from such massive PHP vulnerabilities going forward:
- No longer bundle PHP/httpd for the Linux build of MapGuide at least. Instead we go for integrating with whatever PHP/httpd is offered by the distro (assumed Ubuntu). This way mitigating any future vulnerabilities is now the distro's problem, not ours.
- Or we retain the PHP bundling strategy, but pivot away from bundled PHP being a near-essential component. Why is it near-essential currently? We have various apps (mapadmin/schemareport/fusion/etc) that are written in PHP, so we require it. So how can we make PHP no longer essential? By rewriting mapadmin/schemareport/fusion/etc in .net which has a much better multi-platform and mitigation story. If there is a vulnerability in some .net version, we can just recompile these apps with a newer .net without said vulnerability and be able to ship these updated apps as easy drop-in replacements. Modern .net lets us publish self-contained apps, which negates the need to bundle a runtime environment (the exact problem we have right now with PHP), which makes .net an attractive option for a rewrite. The only problem is the effort in doing the rewrite itself!
Either way, whatever option we go with, it won't take effect in the immediate future. So future 4.0.x releases of MapGuide will unfortunately still have to go with bundling PHP.
Posts
