Los errores de doble liberación se producen cuando se llama a free() más de una vez con la misma dirección de memoria como argumento.



Al llamar a free() dos veces con el mismo valor, se puede producir un buffer overflow. Si un programa llama a free() dos veces con el mismo argumento, las estructuras de datos de administración de memoria del programa se dañan. Esto puede provocar que el programa se bloquee o, en algunas circunstancias, que se realicen dos llamadas posteriores a malloc() para devolver la misma referencia. Si malloc() devuelve el mismo valor dos veces y el programa concede posteriormente al usuario malintencionado control de los datos escritos en la memoria que se ha asignado dos veces, el programa será vulnerable a un ataque de buffer overflow.

Ejemplo 1: en el siguiente código se muestra un sencillo ejemplo de una vulnerabilidad de doble liberación.

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Las vulnerabilidades de doble liberación presentan dos causas habituales (que a veces se superponen):

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

Aunque algunas vulnerabilidades de doble liberación no son mucho más complicadas de las que se indican en el ejemplo anterior, la mayoría se han dispersado en cientos de líneas de código o incluido en diferentes archivos. Los programadores parecen especialmente susceptibles a liberar variables globales más de una vez.

El código fuente que contiene caracteres de control de anulación bidireccional Unicode puede ser signo de un ataque de amenaza interna. Dicho ataque se puede aprovechar a través de la cadena de suministro de lenguajes de programación como C, C++, C#, Go, Java, JavaScript, Python y Rust. Nicholas Boucher y Ross Anderson ya han publicado varias variantes de ataques, incluidas los siguientes: Devoluciones anticipadas, comentarios y cadenas estiradas.
Ejemplo 1: El siguiente código muestra un carácter de control, presente en un archivo de código fuente de C, que lleva a un ataque de devolución anticipada:

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

El carácter de control bidireccional Unicode aislante de derecha a izquierda (RLI), en Example 1, hace que el código se vea de la siguiente manera:

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

Cabe destacar que un desarrollador que realiza una revisión de código, en un editor/visor vulnerable, no vería lo que procesa un compilador vulnerable. En concreto, la instrucción de devolución anticipada que modifica el flujo del programa.

Esta biblioteca es considerada como experimental y no debe utilizarse en entornos de producción a menos que sepa lo que está haciendo.

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa pueda acceder a valores fuera de los límites de la memoria asignada.

Ejemplo: el siguiente lee valores arbitrarios desde la pila porque el número de especificadores de formato no se corresponde con el número de argumentos transferidos a la función.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa convierta incorrectamente valores de datos o que tenga acceso a valores fuera de los límites de la memoria asignada.

Ejemplo: el código siguiente convierte incorrectamente f desde un flotador usando un especificador de formato %d.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

Un Intent interno utiliza una acción personalizada definida por un componente interno. Los intents implícitos pueden facilitar la llamada de intenciones desde cualquier componente externo determinado sin conocimiento del componente específico. La combinación de ambos permite que una aplicación acceda a intenciones especificadas para un uso interno específico desde fuera del contexto de la aplicación deseada.

La capacidad de procesar un Intent desde una aplicación externa puede permitir una amplia variedad de explotaciones de intermediario que varían en gravedad. desde fuga de información y denegación de servicio hasta ejecución remota de código, dependiendo de la capacidad de acción interna especificada por el Intent.

Ejemplo 1: El siguiente código utiliza un Intent interno implícito.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Los intents de Android se utilizan para vincular aplicaciones y componentes de aplicaciones proporcionando instrucciones sobre las acciones que realiza un componente determinado. Los intents pendientes se crean para entregar el Intent más adelante. Los intents implícitos facilitan la llamada de intents desde cualquier componente externo determinado, utilizando un nombre general y un filtro para determinar la ejecución.

Cuando se crea un Intent implícito como PendingIntent, esto podría permitir que el Intent se envíe a un componente no deseado que se ejecuta fuera del contexto temporal previsto, dejando al sistema vulnerable para explotar vectores como la denegación de servicio, la fuga de información privada y del sistema y la escalada de privilegios.

Ejemplo 1: El código siguiente utiliza un PendingIntent implícito.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...