security integer-overflow exploit

security - ¿Cómo es explotable el desbordamiento de enteros?



integer-overflow exploit (5)

¿Alguien tiene una explicación detallada sobre cómo se pueden explotar los enteros? He estado leyendo mucho sobre el concepto, y comprendo lo que es, y comprendo los desbordamientos de búfer, pero no entiendo cómo se puede modificar la memoria de manera confiable, o de una manera de modificar el flujo de la aplicación, haciendo que un entero sea más grande que su memoria definida ....


Depende de cómo se utilice la variable. Si nunca toma decisiones de seguridad basadas en enteros que haya agregado con enteros de entrada (donde un adversario podría provocar un desbordamiento), entonces no puedo pensar en cómo podría meterse en problemas (pero este tipo de cosas pueden ser sutiles).

Por otra parte, he visto un montón de código como este que no valida la entrada del usuario (aunque este ejemplo es artificial):

int pricePerWidgetInCents = 3199; int numberOfWidgetsToBuy = int.Parse(/* some user input string */); int totalCostOfWidgetsSoldInCents = pricePerWidgetInCents * numberOfWidgetsToBuy; // KA-BOOM! // potentially much later int orderSubtotal = whatever + totalCostOfWidgetInCents;

Todo es Hunky-Dory hasta el día en que vendes 671,299 widgets por - $ 21,474,817.95. Jefe podría estar molesto.


Es definitivamente explotable, pero depende de la situación, por supuesto.

Las versiones anteriores ssh tenían un desbordamiento de entero que podía ser explotado de forma remota. El exploit hizo que el demonio ssh creara una tabla hash de tamaño cero y sobrescribiera la memoria cuando intentaba almacenar algunos valores allí.

Más detalles sobre el desbordamiento de enteros ssh: http://www.kb.cert.org/vuls/id/945216

Más detalles sobre el desbordamiento de enteros: http://projects.webappsec.org/w/page/13246946/Integer%20Overflows


Solo quería resumir todo lo que he descubierto sobre mi pregunta original.

La razón por la que las cosas me confundían era porque sé cómo funcionan los desbordamientos de búfer y puedo entender cómo puedes explotar eso fácilmente. Un desbordamiento de enteros es un caso diferente: no puede explotar el desbordamiento de enteros para agregar código arbitrario y forzar un cambio en el flujo de una aplicación.

Sin embargo, es posible desbordar un entero, que se utiliza, por ejemplo, para indexar una matriz para acceder a partes arbitrarias de la memoria. Desde aquí, podría ser posible usar esa matriz mal indexada para anular la memoria y hacer que la ejecución de una aplicación altere su intento malicioso.

Espero que esto ayude.


Un caso común sería el código que evita el desbordamiento del búfer al solicitar el número de entradas que se proporcionarán y luego tratar de imponer ese límite. Considere una situación en la que pretendo proporcionar 2 ^ 30 + 10 enteros. El sistema receptor asigna un búfer de 4 * (2 ^ 30 + 10) = 40 bytes (!). Como la asignación de memoria se realizó correctamente, se me permite continuar. La comprobación del búfer de entrada no me detendrá cuando envíe mi 11ª entrada, ya que 11 <2 ^ 30 + 10. Sin embargo, voy a desbordar el búfer realmente asignado.


Utilicé APL / 370 a finales de los 60 en un IBM 360/40. APL es un lenguaje en el que esencialmente todo es una matriz multidimensional, y existen operadores asombrosos para manipular matrices, incluyendo la remodelación de N dimensiones a M dimensiones, etc.

Como era de esperar, una matriz de N dimensiones tenía límites de índice de 1..k con un k positivo diferente para cada eje .. yk siempre fue legalmente menor que 2 ^ 31 (valores positivos en una palabra de máquina con signo de 32 bits). Ahora, una matriz de N dimensiones tiene una ubicación asignada en la memoria. Los intentos de acceder a una ranura de matriz utilizando un índice demasiado grande para un eje se verifican contra el límite superior de la matriz mediante APL. Y, por supuesto, esto se aplicó a una matriz de N dimensiones donde N == 1.

APL no comprobó si hiciste algo increíblemente estúpido con el operador RHO (array remodelar). APL solo permite un máximo de 64 dimensiones. Por lo tanto, podría hacer una matriz de 1 a 64 dimensiones, y APL lo haría si todas las dimensiones de la matriz fueran menores que 2 ^ 31. O bien, podría intentar hacer una serie de 65 dimensiones. En este caso, APL hizo el tonto y sorprendentemente devolvió una matriz de 64 dimensiones, pero no pudo verificar los tamaños de los ejes. (Esto es en efecto donde se produjo el "desbordamiento de enteros"). Esto significaba que podía crear una matriz con tamaños de eje de 2 ^ 31 o más ... pero al interpretarlos como enteros con signo, se los trató como números negativos.

El conjuro del operador de RHO correcto aplicado a dicha matriz podría reducir el dimensional a 1, con un límite superior de, obtenga esto, "-1". Llama a esta matriz un "agujero de gusano" (verás por qué en este momento). Dicha matriz de agujero de gusano tiene un lugar en la memoria, al igual que cualquier otra matriz. Pero todos los accesos a la matriz se verifican en el límite superior ... pero la verificación de la matriz se realiza mediante una comparación sin firma por APL. Entonces, puedes acceder a WORMHOLE [1], WORMHOLE [2], ... WORMHOLE [2 ^ 32-2] sin objeción. En efecto, puede acceder a la memoria de toda la máquina.

APL también tenía una operación de asignación de matriz, en la que se podía completar una matriz con un valor. WORMHOLE [] <- 0 puso a cero toda la memoria.

Solo lo hice una vez, ya que borró la memoria que contenía mi área de trabajo APL, el intérprete de APL y, obviamente, la parte crítica de APL que permitía el tiempo compartido (en aquellos días que no estaba protegido de los usuarios) ... la sala de la terminal pasó de su estado normal es mecánicamente muy ruidoso (teníamos 2741 terminales Selectric APL) hasta el silencio absoluto en aproximadamente 2 segundos. A través del cristal en la sala de computación, pude ver al operador mirar hacia arriba, sorprendido por las luces en el 370 cuando se apagaron. Un montón de correr alrededor se produjo.

Mientras que era divertido en ese momento, mantuve mi boca cerrada.

Con un poco de cuidado, uno podría haber manipulado el sistema operativo de manera arbitraria.