¿Cuál es el trasfondo del Desbordamiento del contador de referencia en Microsoft TCP / IP (MS11-083)?

La información propia de Microsoft es bastante descriptiva para este problema. Es una vulnerabilidad de desbordamiento de contador de referencia. En términos muy simples, imagina que tienes un trozo de código como este:

size_t num_of_connections = 0;

Así es como se mantendría al tanto del número de conexiones, pero también tiene que lidiar con el hecho de que size_t tiene un tamaño limitado. Si continúa agregando 1 a size_t , eventualmente "desbordará" el valor entero. Lo que sucede en ese punto depende del signo de los datos.

Digamos por un minuto que todos los registros son de 4 bits. Esto no es cierto para su PC, ¡pero mantiene los números viables! Por lo tanto, el valor sin firmar máximo que podemos mantener en un solo registro sería 1111 = 15 . Supongamos que hacemos 15+1 . La respuesta es 10000 = 16 pero eso no encaja dentro de nuestro registro de 4 bits. Hay dos cosas que podrían pasar. Si usas una instrucción estándar de x86 add , ese 1 extra simplemente cae al abismo, para que nunca más se vea. Entonces, el resultado de acuerdo con su programa sería 15+1 = 0 . Si está utilizando adc , el resultado es el mismo, pero el indicador de acarreo se establecería y el siguiente adc también agregaría 1 al resultado. En aras de los intereses, C no usa adc ni usa el indicador de acarreo.

Ahora, la otra alternativa es que estamos usando un valor firmado. En este caso, el valor positivo máximo es 0111 = 7 y el valor negativo máximo es 1111 = 8 (utilizando el complemento de dos). Si agrega uno a siete, todavía se desborda, por lo que 0111+1 = 1000 , lo que implica 7+1 =-8 .

El problema no es que esto suceda, es que usted hace una suposición en su código basándose en el conjunto de valores que pueden aparecer y luego no maneja el caso de un desbordamiento (y por supuesto que un desbordamiento no causará ningún desbordamiento). Excepción o error en absoluto - simplemente sucede). La resta también puede ser un problema, ya que se pasa de valores pequeños a valores grandes porque ha "desbordado" a la inversa. Puede encontrar el artículo de phrack sobre el tema como una lectura bastante interesante.

Entonces, para responder a su pregunta, aunque no conozco detalles específicos, sospecho que el error se debe a que se han enviado paquetes antiguos Permítame aclarar que antes de que estalle una explosión en los comentarios que se encuentran debajo. ... el error probablemente será causado por cualquier paquete antiguo que se envíe, pero es probable que solo cause un bloqueo. Para explotarlo realmente, necesita una forma de obtener la carga útil, es decir, controlar lo que sucede con el bloqueo. Ahí es donde entra en juego la elección de sus paquetes (gracias Hendrik, +1); suficientes de ellos para desbordar cualquier contador de ref que se esté utilizando aquí. ¿Es esta una vulnerabilidad única? En realidad no, es un problema conocido. No es un error en TCP, ya que UDP y TCP son cosas diferentes. Es un error en el manejo de paquetes UDP en la pila TCP / UDP de Microsoft. El manejo de los puertos en los que los servicios no están escuchando sigue siendo un área potencial de riesgo para la seguridad, ya que el sistema operativo debe rechazar correctamente estos paquetes y manejar cualquier posible inundación de dichos paquetes.

Para mitigar dichos problemas en su propio código, consejos del CERT Las directrices de C sobre enteros son útiles, particularmente INT03-C .

  

La vulnerabilidad podría permitir la ejecución remota de código si un atacante envía un flujo continuo de paquetes UDP especialmente diseñados a un puerto cerrado en un sistema de destino.    enlace

Entonces, si bien una gran cantidad de paquetes UDP con todos los bits establecidos en cero puede provocar un bloqueo, es improbable que resulte en la ejecución del código. Deben contener contenido escrito específicamente para explotar el problema.

Es un desbordamiento de contador de referencia según la misma fuente de Microsoft.

¿Qué es un contador de referencia?

Cuando un programa asigna un bloque de memoria, se puede usar un contador de referencia para administrarlo. Cada vez que una parte del código del programa quiere acceder a él, el contador se incrementa. Cada vez que esta parte del código se hace trabajando con el bloque de memoria, el contador disminuye. Cuando el contador llega a 0, nadie más está interesado en el bloque de memoria y se libera.

¿Qué es un desbordamiento de entero?

Los enteros son números que se usan para contar. Tienen un tamaño fijo en memoria de computadora. Por ejemplo, 32 bits o 64 bits. Así que, a diferencia de los enteros, como se sabe a partir de las matemáticas, existe el mayor número posible. Si agrega 1 a ese número, obtendrá un número muy negativo o 0.

En otras palabras, si agregas 1 una y otra vez, terminarás con 0.

¿Qué es una vulnerabilidad del contador de referencia?

Una vulnerabilidad del contador de referencia generalmente es causada por una ruta del programa que no logra disminuir el contador de referencia. Por lo tanto, el atacante puede incrementar el contador una y otra vez.

Como resultado, puede llevar el contador a 0 y más allá (consulte la sección anterior). Después de que el contador se desbordó y terminó en 1 de nuevo, activará la ruta normal del programa que disminuirá el contador.

Ahora el contador llegó a 0. 0 significa que ya nadie está interesado en el bloque de memoria, por lo que se liberará.

¿Cuál es la ruta de error en este contexto?

La ruta del programa que no logra disminuir el contador se usa cuando no hay servicio escuchando en el puerto UDP.

Es fácil concluir que se requiere un puerto UDP abierto para que la disminución final explote el problema. Microsoft, sin embargo, no mencionó esto. Además, declararon que el Firewall de Windows no ofrece protección contra este error. Por lo tanto, la conclusión es probablemente incorrecta.

¿Por qué liberar los bloques de memoria usados es algo malo?

Liberar memoria solo significa que está marcada como "disponible". Por lo tanto, alguien más, que solicita un bloque de memoria, puede obtenerlo. Pero el programa original aún piensa, es dueño del bloque y puede usarlo como quiera.

Así que terminamos con dos programas que usan el mismo bloque de memoria sin ser conscientes de los demás. Esto obviamente lleva a inconsistencias de datos.

Con un poco de mala suerte y un diseño especial, uno de estos programas puede hacer cosas malas al otro. Imagine que el otro programa está almacenando el código del programa, los punteros al código del programa o datos confiables que resultarán en punteros al código del programa en este bloque de memoria.

¿Es esto un riesgo real?

Sí. No es fácil explotar y probablemente se notará el envío de una cantidad tan grande de paquetes UDP a través de una conexión de Internet lenta. Pero es un problema real que necesita ser reparado.