Consideraciones de seguridad en aplicaciones concurrentes

2

He estado creando una aplicación de red con un modelo de Cliente / Servidor, donde un servidor central maneja múltiples hilos de clientes.

Hice todo lo posible para garantizar que, independientemente del contexto en que se ejecute el programa, no se bloquee como parte de un requisito de seguridad.

Mi pregunta es sobre puntos muertos y concurrencia en una aplicación en red que sirve múltiples subprocesos. Un interbloqueo es efectivamente una denegación de servicio, pero ¿puedes realmente explotar un interbloqueo para hacer algo malicioso? ¿Hay consideraciones de seguridad, aparte de los puntos muertos, que debo realizar al crear una aplicación concurrente?

    
pregunta pjmil 15.06.2014 - 05:31
fuente

3 respuestas

1

Cuando se produce un interbloqueo, el procesamiento se detiene. Esta es una denegación de servicio, que, como cualquier otra DoS , puede servir como un paso intermedio para un ataque más grande. Por ejemplo, si un Sistema de detección de intrusiones deja de funcionar (por ejemplo, entra en un interbloqueo), entonces las intrusiones podrán continuar sin ser detectadas . Hollywood, en su infinita sabiduría, ha presentado exposiciones muy gráficas de tales escenarios ( ese es un clásico).

Deadlocks son un problema clásico en la programación concurrente. Son tan clásicos que algunos sistemas incluyen mecanismos de seguridad de "resurrección" que intentan reanimar un proceso más allá de un punto muerto. Por ejemplo, cuando un hilo intenta adquirir un bloqueo que cierra el círculo de interbloqueo, el sistema de bloqueo puede detectarlo y no adquiere el bloqueo, en lugar de eso, informa de un error. Si la persona que llama no comprueba correctamente la condición de error, puede continuar sin el bloqueo, modificando los datos sin sincronización con otras personas que llaman. La corrupción de datos y otras consecuencias indeseables pueden suceder.

Evitar los puntos muertos es una cuestión de corrección : se produce un punto muerto debido a una falla en el diseño general de la aplicación (se considera que los puntos muertos son un tipo de error "difícil" porque no se pueden identificar con precisión). ubicación única donde un programador olvidó poner una prueba o malinterpretó una constante; aparecen errores de interbloqueo en el nivel de la arquitectura). La relación con la seguridad es la genérica: no es suficiente para garantizar que los errores no se activen en condiciones normales, ya que los atacantes a menudo pueden imponer condiciones anormales. Por ejemplo, aunque el nombre de un usuario normal tiene menos de 100 caracteres, debe verificar que el nombre ingresado por el usuario no sea demasiado grande antes de intentar copiarlo en un 100%. búfer de caracteres. De manera similar, incluso si no se puede producir un interbloqueo en una aplicación dada cuando los eventos externos ocurren a un "ritmo normal", un atacante puede activar tiempos inusuales, por ejemplo. iniciando 15 operaciones de "cambio de contraseña" simultáneamente en la misma cuenta.

    
respondido por el Thomas Pornin 15.06.2014 - 15:24
fuente
2

Un interbloqueo, por sí solo, generalmente no permitiría que un atacante afecte el flujo del programa. Por definición, en un punto muerto, el programa deja de avanzar, por lo que en ese momento no ocurre nada: deseable o no deseable.

Hay muchos otros problemas de seguridad posibles en aplicaciones multiproceso:

  • Asegúrese de que los subprocesos sean solo memoria de lectura / escritura para ellos. (Esto es muy amplio, por supuesto, pero depende mucho de su aplicación).
  • Si depende de datos aleatorios (por ejemplo, para claves criptográficas), asegúrese de que los RNG para sus subprocesos no estén en el mismo punto. El uso de los mismos RNG para varios subprocesos puede dar lugar a debilidades criptográficas.
  • Es más probable que las condiciones de carrera ocurran en programas de subprocesos múltiples. Estas condiciones de carrera pueden dar lugar a diversas vulnerabilidades, como problemas de TOCTOU (tiempo de verificación a tiempo de uso) u otros tipos de vulnerabilidades de seguridad.

Hay muchas cosas que pueden salir mal y los problemas específicos que debes buscar dependen en gran medida del tipo de aplicación que estés creando.

    
respondido por el David 15.06.2014 - 06:56
fuente
1

No, no puedes explotar puntos muertos directamente para propósitos maliciosos. Sin embargo, si un procedimiento de seguridad importante se fuerza de alguna manera a un punto muerto, entonces puede dar lugar a una posibilidad de un ataque mayor. Un punto muerto se define como una condición por la cual un programa ya no está progresando, ya sea porque el programa está esperando un recurso no disponible o razones similares. Debe comprender que los puntos muertos generalmente son causados por 2 (o más) acciones / procesos que compiten entre sí, es una condición posible en la mayoría de los sistemas operativos y, por lo tanto, deben manejarse de manera adecuada. La imagen a continuación es un ejemplo simple de lo que sucede en un punto muerto:

  • El proceso 1 necesita el recurso 1, que es propiedad del proceso 2
  • El proceso 2 necesita el recurso 2, que pertenece al proceso 1

(ambos procesos están esperando el recurso deseado en lo que se denomina un "ciclo de espera circular infinito")

Conrespectoaloshilosconcurrentesensuaplicación:

Siestáutilizandohardwaremúltipleparaelprocesamientosimultáneo, enalgunoscasoshayquegestionarmanualmentela"exclusión mutua"  De lo contrario, es altamente probable que ocurra la raza Sin embargo en una sola  plataforma, la exclusión mutua suele ser proporcionada por el sistema operativo y la raza    Las condiciones no ocurren.

    
respondido por el Abbas Javan Jafari 15.06.2014 - 14:45
fuente

Lea otras preguntas en las etiquetas