MOPB-13-2007:PHP 4 Ovrimos Extension Multiple Vulnerabilities

Summary

The Ovrimos extension is an external contributed extension for the Ovrimos SQL Server, which is a client/server, transactional RDBMS combined with Web capabilities and fast transactions.

While looking at the code it was discovered that does not use resources to keep track of connections and internal data structures, but uses direct memory pointers. This is very unsafe and allows direct memory access and code execution.

However the extension is very uncommon and the normal user will have problems compiling it, because the Ovrimos SQL Server development seems to have stopped and the site disappeared.
Affected versions

Affected is PHP <4.4.5
Detailed information

The following code is an example for how the Ovrimos extension is written

PHP_FUNCTION(ovrimos_longreadlen)
{
pval *arg1, *arg2;
PSTATEMENT stmt;

if (getParameters(ht, 2, &arg1, &arg2) == FAILURE) {
    WRONG_PARAM_COUNT;
}
convert_to_long(arg1);
convert_to_long(arg2);

stmt = (PSTATEMENT) Z_LVAL_P(arg1);

stmt->longreadlen = Z_LVAL_P(arg2);
RETURN_TRUE;

}

In this example the first parameter is directly taken as a memory pointer to a STATEMENT structure. And then the value of the second argument is written into the longreadlen field of that structure. This of course allows writting any value to any memory address which usually can be exploited to execute arbitrary code.

Consider this only one of multiple different ways to execute code. Other attack vectors might use ovrimos_close() to call efree() on arbitrary memory addresses which also can lead to code execution.
Proof of concept, exploit or instructions to reproduce

To write any value to any memory address through the Ovrimos extension it is enough to the following code.

<?php
$address = 0xbfbfbfbf /* - sizeof SQLS */;
$value = 0xcccccccc;
ovrimos_longreadlen($address, $value);
?>

Notes

Because the code of the Ovrimos extension is completely broken our recommendation was to unbundle it from the PHP source. The number of users is assumed very low but this protects everyone from activating it by mistake.

We are aware that the impact of this issue is very low, but even low impact vulnerabilities belong into a audit report.