Evasión de la lista de bloqueo de invocación estricta en OGNL mediante proxies de reflexión java.lang.reflect

Resumen

El modo opcional de invocación más estricta (stricter invocation) de OGNL mantiene una lista de bloqueo que impide que las expresiones llamen directamente a métodos en clases peligrosas como Runtime, ProcessBuilder y ClassLoader. La lista de bloqueo filtra según la clase que declara el método que OGNL invoca. Debido a que java.lang.reflect.Method (y Constructor/Field) no estaban en la lista, una expresión puede usar la reflexión como proxy — someMethod.invoke(target, args) — para acceder a un método bloqueado. La llamada real (por ejemplo, ProcessBuilder.start()) se ejecuta en la maquinaria interna de reflexión del JDK y nunca pasa de nuevo por invokeMethod de OGNL, por lo que la lista de bloqueo no la detecta.

Prueba de concepto

Bajo el contexto por defecto de OGNL (acceso solo público, invocación estricta habilitada), la siguiente expresión crea un archivo a pesar de que la llamada directa a new ProcessBuilder(...).start() está bloqueada:

(#pb=new java.lang.ProcessBuilder({"/usr/bin/touch","rce-proof.txt"}),
 #methods=@java.lang.ProcessBuilder@class.getMethods(),
 #names=#methods.{ #this.getName() },
 #startIdx=#names.indexOf("start"),
 #methods[#startIdx].invoke(#pb, null))

Impacto y alcance — lea atentamente

Esto corresponde al refuerzo de una capa secundaria de defensa en profundidad, no a una vulneración del límite de seguridad principal de OGNL.

En OGNL, la lista de bloqueo de invocación estricta es una mitigación secundaria. El control de acceso principal es la implementación de MemberAccess proporcionada por el framework o la aplicación que lo integra, la cual OGNL consulta en cada llamada a constructores y métodos. Se espera que los frameworks que evalúan expresiones no confiables configuren un MemberAccess restrictivo, como por ejemplo SecurityMemberAccess de Apache Struts, que excluye clases peligrosas y el paquete java.lang.reflect. Con un MemberAccess de este tipo, esta prueba de concepto queda bloqueada en el primer paso (el constructor de new ProcessBuilder(...)), antes de que sea posible alcanzar la reflexión.

El contexto por defecto incluido con OGNL permite de forma intencionada todos los miembros públicos y no está diseñado para actuar como sandbox para entradas no confiables. Una aplicación que evalúa expresiones controladas por atacantes con esa configuración permisiva ya cuenta con múltiples vías para ejecutar código, y esta técnica no es indispensable para conseguirlo.

Solo se verá afectado si se cumplen todas las condiciones siguientes:

1. Su aplicación evalúa expresiones OGNL no confiables o controladas por un atacante (1).
2. Utiliza la implementación por defecto permisiva de MemberAccess de OGNL (o una equivalentemente permisiva que admita java.lang.reflect) (2).
3. Confía en la lista de bloqueo de invocación más estricta como su sandbox (3).

Los consumidores configurados correctamente, incluido Apache Struts con su SecurityMemberAccess, no están afectados. La protección real en escenarios con expresiones no confiables sigue siendo un MemberAccess configurado adecuadamente; la lista de bloqueo no debe tratarse como un sandbox.

Corrección

Se han añadido java.lang.reflect.Method, java.lang.reflect.Constructor y java.lang.reflect.Field a la lista de bloqueo de invocación más estricta, impidiendo que los objetos de reflexión se utilicen como proxies de invocación en dicho modo. Se verificó que la vía de java.lang.invoke.MethodHandle no es explotable (sus métodos polimórficos de firma invoke/invokeExact fallan a través de la invocación basada en reflexión de OGNL), por lo que no fue necesario incluir clases adicionales.

Créditos

Reportado de manera responsable a través de Tidelift por 毛锐 (youyi.mr@alibaba-inc.com).