Squiz Matrix CMS 5.5.x.x Code Execution / Information Disclosure

Squiz Matrix CMS suffers from PHP unserialization code execution, information disclosure, and arbitrary file deletion vulnerabilities.

MD5 | 2a89eaa5d695460978b8a6a34c1d28bb

ZX Security identified several vulnerabilities the Squiz Matrix CMS that
can be chained together to gain pre-authenticated remote code execution in
some circumstances.

Affected Versions
The issues in this advisory affect the following versions of Squiz Matrix:
* 5.5.0 prior to
* 5.5.1 prior to
* 5.5.2 prior to
* 5.5.3 prior to

Technical Findings

PHP unserialization of user input may result in remote code execution

When an instance of a Remote Content page exists within a Squiz Matrix CMS
website, user input is passed directly and unsantized to the PHP function
unserialize. In some versions of PHP (e.g. before 5.4.24), this can be
leveraged into a LFI issue. If combined with arbitrary file upload with the
Squiz Matrix CMS website, this leads to remote code execution.

the POST parameter
“page_remote_content_[pageid]_sq_remote_input_file_names” is passed to
unserialize. No generic unserialization gadgets were identified within the
default installation, so the autoloader can be attacked instead.

There are multiple autoloaders that are enabled during the standard Squiz
Matrix execution path. Of note is one found in
vendor/simplesamlphp/saml2/src/_autoload.php. When given a class name that
contains characters such as “.” and “/”, it will directly use these to
include a file. This is a local file inclusion issue within the code,
though is codified within PSR standards, and not normally exploitable. It
should be noted however that underscores are not valid within a filename
included in this method.

Using this class, we can potentially include a file simply by having PHP
attempt to instantiate a class with a malicious name.

There is a second autoloader within the codebase that is not run by
default: vendor/gettext/languages/src/autoloader.php. This autoloader
contains the same kind of issue, however without the underscore limitation
(though with other limitations, such as the class beginning with a certain
string). Once again, this is part of the PSR specification, and not
normally exploitable.

PHP includes within its unserialize function a check on the class name of a
deserialized object to ensure it does not contain invalid characters. This
means we cannot directly trigger the LFI issue using deserialize.

Instead, we can use a more standard deserialize exploitation example, where
we instantiate a class that calls specific code on __destruct. Through
reviewing the codebase, multiple places were found that are applicable to
this case.

vendor/simplesamlphp/simplesamlphp/lib/SimpleSAML/Store/Redis.php. The
destruct method of this class calls the `method_exists` function on the
`$this->redis` variable, which we can control. The `method_exists`
function, among many others, will trigger the autoloader with the first
variable specified (in this case, `$this->redis`, which we control). It
should be noted once again that this is not the same on all versions of PHP
(see references at the end of this advisory).

The last part of exploitation is a deserialize technique called "fast
destruct". This allows an object to be destructed within a single
deserialize call, which allows use to instantiate two classes which trigger
the LFI exploit sequentially within a single request.

Putting together these steps, we can generate an unserialize payload like

$r = new
$r2 = new SimpleSAML\Store\Redis('Gettext\Languages\../../../../x.php'); //
File to include
echo serialize(array($r, $r2));

This gives a payload such as:


If we modify this with the fast destruct method, we get the payload:


Once we send this request to the server on a Remote Page type, we achieve
LFI of a file we previously uploaded to the server, resulting in remote
code execution.

Arbitrary file deletion and information disclosure in file upload form

When an instance of a custom form with a File Upload Field exists within a
Squiz Matrix CMS website, users of the website may be able to delete
arbitrary files from the server through the delete uploaded file feature.
Additionally, this feature discloses the full path of files uploaded to the
server, a form of information disclosure.

When a user uploads a file to a form, they can keep track of the files with
the "prev_files" array, which is rendered in the HTML after a file is
uploaded. This array contains the full path to each uploaded file. The
relevant code can be found in:


An attacker can replace this path to one of their choosing, such as setting
it to "data/private/conf/db.inc", and choose the delete file option. This
deletes the file from the server.

Disclosure Timeline

ZX Security would like to commend the prompt response and resolution of
these reported issues by the vendor.

Vendor notification: August 09, 2019
Vendor response: August 09, 2019
Fixed versions released: August 29, 2019


For more information on the PHP unserailize fast destruct technique, see:
For more information on exploiting the PHP autoloader, including
information on exactly which PHP versions are affected, see:

Related Posts