Security Advisory: Abuse of expressions in midPoint reports

MidPoint expressions embedded in midPoint reports can be used to gain unauthorized access to the system.

There is a critical potential damage that an attacker can cause. By using a scripting expression the attacker can gain the same access as the midPoint application itself, including ability to read files, access database or execute sub-processes. However, the issue can be completely mitigated by a conservative configuration. Therefore, we consider this to be a medium-severity issue.

Most midPoint deployment are not affected by this issue at all. Default midPoint configuration does not allow access that would open this vulnerability to anyone else than system administrator. The configuration needs to be changed in a dramatic way to open this vulnerability.

The recommended mitigation is to maintain best practices of midPoint deployment: never allow untrusted person to specify any kind of expression, especially scripting expression.

However, adhering to that practice will practically prohibit delegation of any expression-related tasks to administrators with reduced privileges. For most of the cases, this can be mitigated by using alternative techniques:

This mitigation is applicable for almost all practical cases in midPoint deployment - with a notable exception of reports. The metarole-based approach is not applicable to reports at all. Lifecycle-based method may be applicable, but it may not be practical. Therefore planned midPoint 4.0 release provides partial solution to limit the power of expression by using Expression Profiles.

Users of midPoint 3.9 or earlier are advised to strictly restrict ability to specify expressions only to the most trusted users. Any user with the ability to specify an expression can gain privileges of midPoint superuser (system administrator). This applies to reports as well as any other use of expressions in midPoint.

Users that plan to deploy midPoint 4.0 can use the ability to restrict reporting expression by using expression profiles. However, this ability is only applicable to reports and it can only be configured globally. The same advice as above applies to all other midPoint expressions.

This is a variation of an issue that is obvious to midPoint community for a very long time. It can be even argued that this is not an issue per se, but it is an inherent consequence of use of scripting expressions in midPoint and therefore it is part of midPoint design. Our point of view is that both arguments are true. As this issue is entwined in midPoint design, it will be difficult to resolve it completely. But that does not mean that we should not try to resolve it eventually.

This is not a characteristic that is unique to midPoint. Almost all systems that can be extended by a general-purpose scripting mechanisms are affected in the same way. The unrestricted capabilities of the expressions may even be required for midPoint deployments to be practical, as midPoint developers cannot predict all the possible use cases for midPoint.

Experience from practical midPoint deployments suggests, that having powerful expressions that need to be strictly controlled is not a critical problem. This applies to all the parts of midPoint except for reporting. Reporting is a special case for several reasons. Firstly, reporting expressions are not executed by midPoint directly. The expressions are executed by JasperReport library, therefore it was difficult to properly control expression environment. Secondly, report definition is one of the task that is often delegated to users with restricted privileges. However, it is almost impossible to create a meaningful report without the use of any expression. When it comes to roles, organizational units and services, metarole-based method can be used. But there is no such option for reports. Therefore we have decided, that there is a need for a solution that can address at least the problem with reports. Such solution is being developed for midPoint 4.0. However, even for midPoint 4.0 this solution will be very limited. Please see Expression Profile Configuration for the details and Expression Profiles: Full Implementation for description of the future plans.

One of the reasons that contributed to the decision to address this issue was a lack of clear documentation. While the danger of generic expressions is very obvious to any experienced software engineer, users that lack deep technical knowledge may get confused. Therefore improvement of the documentation was also a part of mitigation of this issue. The documentation now clearly indicates the risk associated with the use of expressions.

This bug was reported by Martin Lizner by the means of EU-Free and Open Source Software Auditing (EU-FOSSA2) project.