<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Date: 8 Apr 2019<br>
    Severity: Medium (CVSS 4-6.9)<br>
    Affected versions: all midPoint versions<br>
    Fixed in versions: 4.0 (unreleased) - partial fix; workaround exists
    for all midPoint versions<br>
    <br>
    Description<br>
    <br>
    MidPoint expressions embedded in midPoint reports can be used to
    gain unauthorized access to the system.<br>
    <br>
    Severity and Impact<br>
    <br>
    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.<br>
    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.<br>
    <br>
    Mitigation<br>
    <br>
    The recommended mitigation is to maintain best practices of midPoint
    deployment: never allow untrusted person to specify any kind of
    expression, especially scripting expression.<br>
    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:<br>
    * Metaroles can be used to group all the necessary logic, including
    expressions. Meta roles can be setup by a trusted administrator.
    Delegated administrators then just "use" the metarole, with possible
    parametrization using parameters in assignment extension. However,
    even this method is not yet fully supported in midPoint user
    interface.<br>
    * Object lifecycle mechanism can be used to drive role definitions
    through an approval process. This can be used to make sure that
    expressions used in the roles are safe.<br>
    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.<br>
    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.<br>
    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.<br>
    <br>
    Discussion and Explanation<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Credit<br>
    <br>
    This bug was reported by Martin Lizner by the means of <span
      class="external-link">EU-Free and Open Source Software Auditing
      (EU-FOSSA2) project</span>.<br>
    <br>
    See Also<br>
    <br>
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/Security+Advisory%3A+Abuse+of+expressions+in+midPoint+reports">https://wiki.evolveum.com/display/midPoint/Security+Advisory%3A+Abuse+of+expressions+in+midPoint+reports</a><br>
    <br>
    <a class="moz-txt-link-freetext"
href="https://wiki.evolveum.com/display/midPoint/Security+Advisory%3A+MidPoint+user+interface+clickjacking"></a>
    <pre class="moz-signature" cols="72">-- 
Radovan Semancik
Software Architect
evolveum.com
</pre>
  </body>
</html>