¿Por qué el bloqueo de la aplicación se considera inseguro?

1. Se bloqueó porque alguna entrada no se procesó correctamente. Un atacante puede intentar encontrar la ruta del código que conduce al procedimiento defectuoso e intentar ejecutar código arbitrario a través de posibles vulnerabilidades.

2. Los bloqueos pueden proporcionar a un atacante información valiosa sobre el sistema y sus detalles internos.

3. Los bloqueos pueden crear vulnerabilidades temporales o dejar archivos no protegidos (por ejemplo, volcados de memoria) que pueden ser explotados.

4. (Gracias y una sugerencia de sombrero vaya a Ladadadada ) La aplicación que se bloquea debe reiniciarse, lo que obviamente lleva tiempo (incluso con sistemas de vigilancia y esquemas de conmutación por error simétricos). Si un atacante replica las condiciones que llevaron a la falla, su servicio sufrirá una interrupción prolongada ( Denegación de servicio ) lo que significa pérdidas financieras, de reputación y otras.

Como respuesta anterior, hemos cubierto la mayor parte del escenario en el que el atacante puede obtener un beneficio directo al analizar los bloqueos de aplicaciones. Recomendaré leer en "Analizar bloqueos para encontrar vulnerabilidades de seguridad en sus aplicaciones" . El análisis de bloqueos en busca de vulnerabilidades de seguridad puede requerir habilidades de programación de bajo nivel. Como se muestra en la figura 1, es posible que cualquier vulnerabilidad no genere una vulnerabilidad de seguridad y define una ruta de investigación para analizar los bloqueos de aplicaciones.

Para generalizar la respuesta de Deer Hunter:

• Si una aplicación falla, significa que lo que está sucediendo no se espera y no se comprende.
• Si no se espera y no se comprende, no tiene forma de saber si es seguro.
• Por lo tanto, debe asumir que no es seguro.

Tenga en cuenta que simplemente capturar y descartar una excepción inesperada es también inseguro y no debe hacerse. Terminar el proceso es mejor que continuar en un estado inconsistente inesperado.

Esto es esencialmente el destilado del Apéndice de Feynman:

  

(...) la erosión y la explosión no son lo que el diseño esperaba. Son advertencias de que algo está mal. El equipo no está funcionando como se esperaba y, por lo tanto, existe el peligro de que pueda operar con desviaciones aún más amplias de esta manera inesperada y no entendida a fondo. El hecho de que este peligro no haya provocado una catástrofe antes no es garantía de que no lo hará la próxima vez, a menos que se entienda completamente.

Puede encontrar el documento completo aquí:

• enlace

Esta es una lectura recomendada para todos los desarrolladores de software, especialmente aquellos que tienen el hábito de detectar excepciones que no comprenden completamente.

Un bloqueo de aplicación es el resultado de un comportamiento inesperado y no manejado. Esto significa que hay un error en la aplicación que se bloqueó, y numerosos errores llevan a vulnerabilidades.

Uno de los bloqueos más peligrosos es el bloqueo debido a la corrupción de la memoria (fallo de segmentación). Este tipo de errores a menudo se pueden explotar para hacer que la aplicación vulnerable ejecute un código arbitrario (malicius).

Además, una forma de bloquear un software puede usarse en ataques de denegación de servicio.

Está fusionando dos eventos diferentes: detener y bloquear

• Si una aplicación realmente se detiene limpiamente, ya no puede hacer ningún daño
• Si una aplicación falla, puede mostrar todo tipo de comportamiento indefinido e inesperado como se muestra en otras respuestas. "Detener" es solo un resultado. También puede comenzar a usar el 100% de la CPU de forma indefinida, lo que lleva a todo tipo de otros problemas.

Ciertos tipos de bloqueos se conocen como "Violaciones de acceso", son los Bloqueos / Anomalías que "violan" la regla definida por los programadores que escribieron el sistema / software / sistema operativo o los programadores que escribieron compiladores que hacen ejecutables.

Supongamos que el atacante (Neo) encuentra un bloqueo en uno de los programas (Matrix) que puede usar ese bloqueo para "violar" la regla (las reglas se definen para Matrix) y puede usar ese bloqueo para tomar el control del sistema ( Matrix) y ahora quiere realizar una actividad maliciosa (desactivar la matriz) porque conoce una llamada a la API, pero esa llamada a la API está controlada / vigilada por otro programa / antivirus (Agente Smith), pero desde que obtuvo el control total sistema (matriz) puede cerrar Antivirus (Agente Smith) y ahora puede cerrar el sistema (Matriz)

Dado que esto afectará la confidencialidad, la integridad y la disponibilidad del sistema, estos bloqueos se consideran problemas de seguridad.

Muchas aplicaciones se caen, no todas, pero muchas implican que la máquina ejecuta algo que no debería haber hecho. La máquina salta a algo que cree que se supone que es un código, pero en realidad se trata de datos aleatorios (o al menos datos que no se han preparado como código). La máquina intenta ver estos datos como código, pero no tiene ningún sentido como código, por lo que la máquina no sabe qué hacer. Cuando eso sucede, la aplicación se bloquea.

Pero lo que pasa con los errores es que si sabes cómo activarlos, puedes activarlos deliberadamente. A veces, dependiendo de cómo funciona el error, incluso puede controlar en qué datos salta la máquina. Esa posibilidad es lo que hace que la gente de seguridad se ponga nerviosa: si puede hacer que la máquina salte a datos que no tienen ningún sentido, y puede controlar cuáles son esos datos, entonces podría hacer que la máquina salte a algo que hace tiene sentido. Una vez que haya configurado esto, podría hacer que la máquina haga más o menos lo que quiera .

No todos los bloqueos de aplicaciones funcionan de esta manera. La respuesta de @ AliAhmad muestra los conceptos básicos de cómo decir lo que puede y lo que no. Pero debido a que las consecuencias de un choque inseguro pueden ser tan graves, cada choque debe revisarse para ver si es "seguro" o no.