Multi-tenancy y Heartbleed

1

Utilizamos un proveedor de servicios conocido / puerta de enlace de administración de API que se encuentra frente a nuestras API RESTful que proporcionan funcionalidad de administración de claves, etc. etc.

El proveedor de servicios estaba ejecutando la versión poco fiable de OpenSSL.

Ninguno de nuestros servicios web tiene SSL habilitado, aunque usamos claves de API para acelerar el acceso a la API y medir el uso.

El tráfico, obviamente, llega a los servidores web del proveedor de servicios, que actúa como un proxy y habla con nuestros servidores web.

Si la infraestructura del proveedor de servicios es tal que muchos clientes comparten una instancia de servidor web y al menos un cliente tiene SSL habilitado, ¿eso expone a todos los clientes, incluidos aquellos que no usan SSL, a la amenaza?

Aparentemente, el error no permite leer la memoria fuera del espacio de direcciones del proceso, por lo que la respuesta se basa en cómo el servidor web proxy ejecuta un proceso por cliente.

¿Alguien ha cubierto este escenario?

Escenario hipotético

Soy un programador que trabaja para APIs-r-Us. En lugar de ejecutar un sitio web y un proceso separados para cada uno de mis miles de clientes, fragmentando y todo eso, escribo el sistema proxy como un solo servicio web sin estado que se ejecuta en una instancia de sitio web que maneja todas las solicitudes a apisrus.net

Mi servicio maneja tráfico SSL y no SSL.

Mi servicio usa algunas reglas basadas en la URL para enrutar solicitudes a diferentes servicios web de clientes. Los consumidores de API hablan con mi servicio y mi servicio con el servicio real del cliente, las cargas útiles pueden incluso ser convertidas o aumentadas por mi servicio antes de ser devueltas al consumidor de API.

Cargadas en la memoria del proceso están las diversas rutas y credenciales para acceder a las API de mi cliente, así como las claves y los hashes que se usan para autenticar a los usuarios.

Todo el tráfico se dirige a través de un solo proceso, por lo que si la memoria de este proceso se ve comprometida, todos los clientes se ven comprometidos.

Supongo que OpenSSL se carga en el espacio de direcciones del sitio web (y no en la canalización del servidor).

    
pregunta Luke Puplett 15.04.2014 - 12:17
fuente

3 respuestas

2

La respuesta a tu escenario específico es "depende".

Específicamente, depende de los detalles más precisos de cómo funciona el asignador de memoria de la aplicación, el mecanismo de subprocesamiento que utiliza y la estructura interna de la aplicación. Hay algunos escenarios (p. Ej., La antigua bifurcación fork + exec con una nueva hebra para manejar cada solicitud, o un asignador de memoria que siempre borra la memoria antes de usar más las agrupaciones de memoria por hebra más hebras dedicadas SSL y no SSL) en las cuales Los datos que no son SSL no pueden filtrarse en el espacio de memoria accesible a OpenSSL. Sin embargo, a menos que sepa que uno de estos es el caso, debe asumir que cualquier cosa en la memoria del servidor web puede haber sido filtrada por Heartbleed.

    
respondido por el Mark 14.08.2014 - 08:40
fuente
0

Si reanudo correctamente su situación en el siguiente dibujo (perdón por la fealdad):

Entonces, no estás en riesgo , ya que los datos entre tus clientes - > el proveedor - > sus servidores no están encriptados y luego no pasan por la memoria del proceso OpenSSL.

El servidor vulnerable aún puede ser explotado para volcar claves privadas / datos de clientes para otros usuarios y otros servicios que no sean los suyos, pero como el ataque Heartbleed no puede leer la memoria de otros procesos (hasta donde saber hoy), usted no está afectado.

Como nota adicional, como señaló Lucas Kauffman, el hecho de que sus datos no estén encriptados entre sus clientes y sus servidores web es probablemente un riesgo más grave que la vulnerabilidad de Heartbleed.

    
respondido por el ack__ 15.04.2014 - 12:52
fuente
0

Heartbleed es un error de raspado de memoria. No son solo las claves que se pueden encontrar, sino CUALQUIER información que manejó la máquina afectada. En el caso de este proxy, entonces, la vulnerabilidad del corazón podría ver la memoria en otro proceso, que resultó ser la solicitud HTTP de su cliente a su servidor. Debido a la naturaleza de esta falla, CUALQUIER información sensible que haya pasado por esa máquina debe considerarse comprometida.

    
respondido por el Ryan Gooler 14.08.2014 - 00:43
fuente

Lea otras preguntas en las etiquetas