Aquí está la declaración: fprintf(stderr, "Some random string\n").
¿Está bien no tener un especificador de formato, como% s, a pesar de que la declaración no acepta ninguna entrada del usuario? ¿Sigue siendo potencialmente explotable? Parece que, al menos, todavía debe considerarse como una buena práctica incluir un especificador de formato. Apreciaría un poco de claridad al respecto. Gracias.
La declaración, como lo muestra, no es vulnerable a nada. Sin embargo, fprintf() es de hecho un intérprete por derecho propio: lo que toma como cadena de formato no es solo una secuencia de caracteres; es el código fuente de un idioma específico con directivas que comienzan con un signo '%'.
Cuando uses tu función fprintf() de esa manera, tarde o temprano, algunos desarrolladores se volverán genéricos, justos y fanáticos de la internacionalización, e insistirán en reescribirla de esa manera:
/* in some .h file */
#define MSG_EN_42 "Some random string\n"
#if LANGUAGE_IS_ENGLISH
#define MSG_42 MSG_EN_42
#endif
/* in another .c file */
fprintf(stderr, MSG_42);
Luego, algunas semanas / meses / años más tarde, otro desarrollador, con poca comprensión de C pero con un conocimiento notable de alemán / Thaï / Klingon, cambiará el .h para que se vea así:
/* in some .h file */
#define MSG_EN_42 "Some random string\n"
#define MSG_KG_42 "fs'k5 f%n59 #$dsai!\n"
#if LANGUAGE_IS_ENGLISH
#define MSG_42 MSG_EN_42
#endif
#if LANGUAGE_IS_KLINGON
#define MSG_42 MSG_KG_42
#endif
Y luego surgen problemas.
(No es un ejemplo real de Klingon, por cierto; usar palabras Klingon verdaderas en el desprevenido lector sería un poco grosero. Pero entiendes la idea)
Para anular estos problemas , use una cadena de formato cuando se deba una cadena de formato. Esto llevaría a:
fprintf(stderr, "%s", "Some random string\n");
o, como una solución más simple:
fputs("Some random string\n", stderr);
Lea otras preguntas en las etiquetas exploit buffer-overflow c