¿Agregar 65K de búfer para proteger de los desbordamientos de búfer?

13

Si tuvieras una función muy compleja e importante en C que quisieras proteger, ¿valdría la pena colocar un búfer de 65 K en la parte superior de la pila para protegerlo de los desbordamientos de búfer? Debería poner sus búferes importantes debajo del búfer de 65 K para que la pila tenga este aspecto:

[Saved EIP] // higher adddresses
[   ...   ]
[   65K   ]
[   ...   ] // other stack variables and buffers

De esta manera, si hubiera un desbordamiento de búfer por debajo de los 65K, se desbordaría en el búfer de 65K y no alcanzaría las variables de la pila.

¿Es esta una defensa factible contra los desbordamientos de búfer?

    
pregunta John 22.06.2014 - 01:06
fuente

4 respuestas

26

No. Lo más probable es que obtuviste ese límite de 64k del error Heartbleed , hovewer es simplemente porque en HTTPS Heartbeats el campo de longitud era 16 bits de largo No significa que, en su caso, su software no tendrá un desbordamiento de búfer que llegue más lejos. Entonces, sí, esto podría agregar un poco de seguridad, siempre debe asumir que los desbordamientos de búfer pueden afectar todo su espacio de direcciones, tanto después del búfer como incluso antes.

    
respondido por el MaxSem 22.06.2014 - 01:24
fuente
19

El mejor consejo para evitar errores de desbordamiento de búfer en C es no usar C en primer lugar. La filosofía de diseño del lenguaje era que cada vez que tenían que elegir entre eficiencia y seguridad, elegían la eficiencia. El resultado es un lenguaje que se puede utilizar para escribir programas muy rápidos y que conservan la memoria, pero desafortunadamente a expensas de la seguridad. Eso significa que es arriesgado usarlo en cualquier contexto donde la seguridad sea relevante, y en el mundo de la red de hoy en día está virtualmente en todas partes.

El segundo mejor consejo es no usar funciones que escriben en búferes pero no tienen un argumento de longitud máxima, como el siguiente:

  • obtiene
  • scanf
  • sprintf
  • strcat
  • strcpy

La mayoría de estos tienen versiones alternativas con n en el nombre que tienen un parámetro adicional para la longitud máxima. Use estos y asegúrese de que este parámetro nunca sea mayor que la longitud del búfer de cadena que pasa. Pero tenga en cuenta que puede still generar una vulnerabilidad de desbordamiento del búfer al pasar accidentalmente una longitud más pequeña que el búfer objetivo.

    
respondido por el Philipp 22.06.2014 - 04:04
fuente
7

Uno de los enfoques de seguridad conocidos es colocar un "canario" en la pila que se dañaría (modificará) por el desbordamiento del búfer, si ocurriera alguno. No tiene que ser tan grande, y debe inicializarse con algunos valores que es poco probable que el programa de ataque sepa.

Después de hacer un IO, puedes verificar si el desbordamiento del búfer no ha tocado el contenido de este búfer.

Sin embargo, esta protección solo funciona si está seguro de que recuperará el control de ejecución después del desbordamiento. Si la saturación daña la dirección de retorno que utiliza la función IO, es posible que no tenga la posibilidad de realizar la comprobación de canario.

Sin embargo, con la pila descendente típica donde la dirección de retorno es la última entrada con una dirección más pequeña y el búfer se desborda (por lo tanto, lejos de la dirección de retorno), el canario debería funcionar:

  (higher address values)
  other stack data
  canary
  buffer that overruns up
  return address from the IO routine
  (lower address values)

Debes poder regresar, revisar el canario y si está muerto, terminar el programa de la manera más rápida posible.

    
respondido por el h22 22.06.2014 - 11:10
fuente
1

Algunos contadores de búferes son de 16 bits, lo que significa que 65k protegerían; sin embargo, la mayor parte del tiempo no es el caso y 65k es un lote de espacio de pila para desperdiciar.

En general, una idea mal pensada.

    
respondido por el Joshua 23.06.2014 - 00:12
fuente

Lea otras preguntas en las etiquetas