ALGUNOS EJEMPLOS DE CÓDIGO VULNERABLE Y CÓMO ENCONTRARLOS

He recomendado previamente un curso titulado Los exploits de software de Formación de Seguridad abierto, y de manera similar, un libro "llamado El Manual del Shellcoder: Agujeros de descubrir y de seguridad Explotando". El uso de algunos de los ejemplos presentados en el libro, pensé que sería una buena idea para explorar cómo la teoría de las vulnerabilidades de código reales sigue siendo verdad.

DATOS DE LA COPIA

Uno de los escenarios más simples en los cuales código vulnerable puede manifestarse - que por lo general se pueden observar de inmediato - va de la mano con la copia de los datos del buffer utilizando funciones tales como  strcpy , sin realizar ninguna comprobación sobre el tamaño de la copia.

La parte anterior muestra del código vulnerable en la Universidad de Washington  servidor IMAP , que fue corregido en 1998. Podemos ver que nunca se comprueba el tamaño de los datos en el  mecanismo  antes de copiar a  tmp , lo que podría provocar un desbordamiento del búfer. El error se resuelve fácilmente mediante un control con  strlen (mecanismo)  antes de copiar, o mediante el uso de n bytes de funciones de copia, como  strncpy .

Como se puede imaginar, es muy raro estos días para este tipo de vulnerabilidades que se encuentran en aplicaciones de código abierto; y, cuando existen, son corregidos rápidamente.

ÍNDICES INCORRECTOS EN BUCLES

Cuando los índices o las condiciones de corte en los bucles iterativos están mal programados, puede dar lugar a más bytes que se están copiando lo que se pretendía: ya sea un byte ( off-by-one ) o varias ( off-by-a-pocos ). Tomemos, por ejemplo, esta versión antigua del  OpenBSD demonio FTP:

Mientras que el propósito del código es reservar un byte para el carácter nulo al final de la cadena, cuando el tamaño del  nombre  es igual o mayor que  npath , y el último byte a ser copiado es "(comillas dobles), podemos ver que el índice  i  se incrementa en más en el comando resaltado. Este resultado en el carácter nulo se insertan un byte más allá del límite, generando un desbordamiento.

Los bucles que se encargan de analizar cadenas o las entradas del usuario tienden a ser buenos lugares para buscar vulnerabilidades, como se muestra en el ejemplo a continuación, de nuevo tomada de la Universidad de servidor IMAP de Washington (CVE-2005-2933):

En la línea 20, hay una búsqueda de un signo de comillas dobles dentro de la cadena que se está analizando. Si se comprueba, el bucle en la línea 22 se copia hasta que se encuentre una segunda comilla doble. Claramente, si una cadena está introducida que sólo tiene un carácter tal, el bucle mantendrá la copia, que resulta en una pila de desbordamiento.

DESBORDAMIENTO DE ENTEROS

Una cosa que puede suceder a menudo cuando se trata de evitar una cantidad excesiva de copia de datos a un búfer - comprobando el tamaño para ser copiado - es que el número de bytes a copiar excede el número más grande que puede ser representado por el tipo de datos, girando hacia valores más pequeños. La comprobación termina siendo completado sólo por el tamaño se interpreta como un número pequeño, pero la copia se compone realmente de un gran número de elementos. Esto da como resultado un desbordamiento de la memoria intermedia de destino.

Un ejemplo de esto es cuando se utiliza una multiplicación que produce resultados muy grandes, como en este  OpenSSH código, que aparece en las versiones anteriores a 3.4:

Podemos ver que  nresp  almacena el tamaño de un paquete introducida por el usuario. En el comando resaltado,  nresp  se multiplica por el tamaño de un cursor (4 bytes). En consecuencia, si  nresp  almacena un valor mayor que 1073741823, la multiplicación excederá el valor máximo de  unsigned int  (4294967295). En otras palabras,  malloc  se reserva una pequeña cantidad de memoria y el bucle copiar una gran cantidad de datos, produciendo un desbordamiento. Este tipo de vulnerabilidad es todavía relevante y común hoy en día.

Estos son sólo unos pocos tipos de vulnerabilidades, y recomiendo mirar el libro que he mencionado antes para más ejemplos. Mientras que algunos, como el  strcpy tipo, son ahora muy poco común en las aplicaciones de código abierto de hoy, su presencia viva en aplicaciones cerradas o propietarias, o aquellos que nunca han sido objeto de una auditoría de código.

Como regla general, cuando se busca vulnerabilidades en el código de fuente abierta, es recomendable comprobar porciones de código que rara vez se ejecuta, con todas las funciones especiales, ya que son más  propensos a errores . Además, como ya se ha mencionado, cuando los desarrolladores aplican sus propias funciones para el análisis o cadenas de manipulación, tramas de datos, y así sucesivamente, que aumenta la posibilidad de que se cometan errores.

Fuente: http: //www.welivesecurity.com/

CONOCIMIENTO pertenece al mundo