An unauthenticated arbitrary object instantiation vulnerability in LDAP Account Manager (LAM) has been discovered during an internal penetration test.
LAM is a PHP web application for managing entries such as users, groups, or DHCP settings in LDAP directories via a web frontend, and is one of the alternatives to FreeIPA. It’s included in Debian repositories.
But a vulnerability discovered by researcher Arseniy Sharoglazov could allow an attacker to create arbitrary objects and achieve remote code execution (RCE) in one request, and without any out-of-band connections.
Under construction
The technique depends on exploiting the construction new $a($b), with the variable $a standing for the class name that the object will be created for, and the variable $b denoting the first argument to be passed to the object’s constructor.
“When you code in any programming language, you can use good or bad programming practices. The usage of the construction new $a($b), which instantiates arbitrary objects, is a bad practice, if $a and $b come from a non-controlled input,” Sharoglazov tells The Daily Swig.
“It’s a dodgy construction. However, no one showed that it’s really dangerous, so some people think that everything should be alright.”
While the technique requires the Imagick extension, he says, this is usually present in larger websites, including the LAM system itself.
Sharoglazov says that similar arbitrary object instantiation vulnerabilities have been around for quite some time, but aren’t usually reported as such.
“For example, you might read about an SSRF in a commercial software. If you knew the PoC, you would see that it’s actually an arbitrary object instantiation with the usage of the SoapClient class, for instance. But for the public it will be just SSRF,” he says.
“Or you might read about an SQL injection. But it’s actually an arbitrary object instantiation exploited via a user-defined class which has an SQL injection. This technique, which I found and described, shows how to exploit an arbitrary object instantiation directly to RCE.”
Coordinated disclosure
Sharoglazov says the disclosure process went quickly and efficiently. He first reported the flaw on 16 June, with LAM 8.0.1 released on June 29, Debian packages updated on July 5, and public disclosure on July 14.
“I wrote to Roland Gruber, the developer of LAM, and I got an initial reply in just one hour,” he says.
“We discussed what needs to be done to fix the vulnerabilities, and the hardening process that will make LAM way more secure. Afterwards, we did a coordinated disclosure with him and Debian.”
Source: https://portswigger.net/daily-swig/ldap-account-manager-bug-poses-unauthenticated-remote-code-execution-risk
