char *strcpy( char *dest, const char *src );

Básicamente nos está diciendo, "venga, dime de donde tengo que leer (src) y donde lo tengo que escribir (dest); y además te devolveré misma dirección de memoria de destino que tú mismo me has pasado" Eficaz, ¿eh?. Naturalmente, C (y su hermano mayor, C++), no poseen gestión automática de la memoria dinámica ni realiza una gestión de chequeo de límites en los búfer que trata. Esto no viene de serie. 

Cuando se usaba esta función los programadores no se quebraban mucho la cabeza. 'strcpy', para de copiar cuando encuentra un carácter nulo. El problema empieza cuando no lo encuentra. Seguirá copiando y copiando hasta que lea un carácter nulo de 'src'. Y por supuesto, seguirá escribiendo en 'dest'...aunque el límite del búfer designado haya sido rebasado varias veces, de ahí la denominación de desbordamiento.

Para enmendar el fallo, 'strcpy' evolucionó para "controlar" el tamaño del búfer. Ese controlar entrecomillado denota ironía. Cómo 'strcpy' no tomaba en cuenta el tamaño de búfer, sino que se limitaba a buscar un carácter nulo, había que buscar una solución y está, en aquellos tiempos, fue un...ejem...parche...mmm...considerable. Incluso el propio manual de GNU libc destaca:

This function was designed for now-rarely-used arrays consisting of non-null bytes followed by zero or more null bytes. It needs to set all size bytes of the destination, even when size is much greater than the length of from. As noted below, this function is generally a poor choice for processing text.

Dentro interfaz de "strncpy":




Ahora tenemos un tercer parámetro para que el programador designe el tamaño de búfer requerido, es decir, la pelota en el otro campo. El perfecto, "Ah, yo qué sé, tú me dijiste qué...". ¿Servía esto de algo? Pues no de mucho. Básicamente porque cuando se calculaba el parámetro "count", su expresión no era precisamente un simple número natural, sino que se abusó hasta límites matemáticamente inconcebibles para definir el tamaño. 

Además, la función no solo se limitaba a copiar los 'n' caracteres designados, lo hace pero no deja sitio para el carácter nulo de terminación de línea '\0'. Por lo que cuando la cadena era vuelta a tratar esta no tenía virtualmente fin, ya que no disponía de carácter terminador que la limitará.

No solo eso, también da pie a horrores que parecen el producto de la muerte por deadline, como equivocar el orden de los parámetros y poner el tamaño entre los dos búfer de fuente y destino...y no es precisamente una muestra de tiempos pasados, el CVE es de 2018. 

Una última muestra de hasta donde llegan los problemas con el uso de funciones inseguras: un desbordamiento de búfer al corregir con 'strncat' un desbordamiento de búfer causado por usar 'strcat'. Esta fenomenal carambola está mejor explicada aquí.

root@bokchoy:~/tes/apache_1.3.33/src/support# diff -uN  htpasswd.orig.c htpasswd.c
--- htpasswd.orig.c     2004-10-28 18:20:13.000000000 -0400
+++ htpasswd.c  2004-10-28 18:17:25.000000000 -0400
@@ -202,9 +202,9 @@
        ap_cpystrn(record, "resultant record too long", (rlen - 1));
        return ERR_OVERFLOW;
     }
-    strcpy(record, user);
+    strncpy(record, user,MAX_STRING_LEN - 1);
     strcat(record, ":");
-    strcat(record, cpw);
+    strncat(record, cpw,MAX_STRING_LEN - 1);
     return 0;
 }

(fuente: https://blogs.msdn.microsoft.com/michael_howard/2004/10/29/buffer-overflow-in-apache-1-3-xx-fixed-on-bugtraq-the-evils-of-strncpy-and-strncat/) 

Programar en C o C++ no es fácil, aunque sí que es divertido, ya que dispones de una libertad y potencia que resulta difícil de alcanzar en otros lenguajes o entornos de ejecución. Tenemos a los nuevos vecinos Rust y Go, pero estos chicos aún tienen mucho que demostrar para destronar 40 años de reinado.

Sin duda, parte de la leyenda negra lo suponen estas funciones inseguras, procedentes de otros tiempos, donde aún no existía base de conocimiento alguna. No obstante, los compiladores modernos, librerías y nuevas herramientas pueden amortiguar lo que las prisas y la inexperiencia pueden causar.