Pourquoi printf avec un seul argument (sans spécificateurs de conversion) est-il obsolète?

Dans un livre que je lis, il est écrit printfqu'avec un seul argument (sans spécificateurs de conversion) est obsolète. Il recommande de remplacer

printf("Hello World!");

avec

puts("Hello World!");

ou

printf("%s", "Hello World!");

Quelqu'un peut-il me dire pourquoi printf("Hello World!");est faux? Il est écrit dans le livre qu'il contient des vulnérabilités. Quelles sont ces vulnérabilités?

printf("Hello World!"); IMHO n'est pas vulnérable mais considérez ceci:

const char *str;
...
printf(str);

S'il strarrive à pointer vers une chaîne contenant des %sspécificateurs de format, votre programme affichera un comportement indéfini (principalement un plantage), alors puts(str)qu'il affichera simplement la chaîne telle quelle.

Exemple:

printf("%s");   //undefined behaviour (mostly crash)
puts("%s");     // displays "%s\n"

printf("Hello world");

est bien et n'a aucune vulnérabilité de sécurité.

Le problème réside dans:

printf(p);

où pest un pointeur vers une entrée contrôlée par l'utilisateur. Il est sujet aux attaques de chaînes de formatage : l'utilisateur peut insérer des spécifications de conversion pour prendre le contrôle du programme, par exemple %xpour vider la mémoire ou %npour écraser la mémoire.

Notez que son puts("Hello world")comportement n'est pas équivalent à printf("Hello world")mais à printf("Hello world\n"). Les compilateurs sont généralement assez intelligents pour optimiser ce dernier appel pour le remplacer par puts.

En plus des autres réponses, il printf("Hello world! I am 50% happy today")y a un bug facile à faire, causant potentiellement toutes sortes de problèmes de mémoire désagréables (c'est UB!).

Il est simplement plus simple, plus facile et plus robuste de «demander» aux programmeurs d'être absolument clairs lorsqu'ils veulent une chaîne textuelle et rien d'autre .

Et c'est ce qui printf("%s", "Hello world! I am 50% happy today")vous attire. C'est totalement infaillible.

(Steve, bien sûr, ce printf("He has %d cherries\n", ncherries)n'est absolument pas la même chose; dans ce cas, le programmeur n'est pas dans l'état d'esprit "chaîne verbatim"; elle est dans l'état d'esprit "chaîne de formatage".)

Je vais juste ajouter quelques informations concernant la partie vulnérabilité ici.

On dit qu'il est vulnérable en raison de la vulnérabilité du format de chaîne printf. Dans votre exemple, où la chaîne est codée en dur, elle est inoffensive (même si le codage en dur de telles chaînes n'est jamais entièrement recommandé). Mais spécifier les types de paramètres est une bonne habitude à prendre. Prenons cet exemple:

Si quelqu'un met un caractère de chaîne de format dans votre printf au lieu d'une chaîne régulière (par exemple, si vous voulez imprimer le programme stdin), printf prendra tout ce qu'il peut sur la pile.

Il était (et est toujours) très utilisé pour exploiter des programmes en explorant des piles pour accéder à des informations cachées ou contourner l'authentification par exemple.

Exemple (C):

int main(int argc, char *argv[])
{
    printf(argv[argc - 1]); // takes the first argument if it exists
}

si je mets en entrée de ce programme "%08x %08x %08x %08x %08x\n"

printf ("%08x %08x %08x %08x %08x\n"); 

Cela indique à la fonction printf de récupérer cinq paramètres de la pile et de les afficher sous forme de nombres hexadécimaux remplis à 8 chiffres. Ainsi, une sortie possible peut ressembler à:

40012980 080628c4 bffff7a4 00000005 08059c04

Voir ceci pour une explication plus complète et d'autres exemples.

L'appel printfavec des chaînes de format littérales est sûr et efficace, et il existe des outils pour vous avertir automatiquement si votre appel printfavec les chaînes de format fournies par l'utilisateur n'est pas sûr.

Les attaques les plus sévères printftirent parti du %nspécificateur de format. Contrairement à tous les autres spécificateurs de format, par exemple %d, %nécrit en fait une valeur dans une adresse mémoire fournie dans l'un des arguments de format. Cela signifie qu'un attaquant peut écraser la mémoire et ainsi potentiellement prendre le contrôle de votre programme. Wikipedia fournit plus de détails.

Si vous appelez printfavec une chaîne de format littérale, un attaquant ne peut pas se faufiler %ndans votre chaîne de format et vous êtes donc en sécurité. En fait, gcc transformera votre appel printfen un appel à puts, donc il n'y a littéralement aucune différence (testez ceci en exécutant gcc -O3 -S).

Si vous appelez printfavec une chaîne de format fournie par l'utilisateur, un attaquant peut potentiellement insérer un %ndans votre chaîne de format et prendre le contrôle de votre programme. Votre compilateur vous avertira généralement que le sien n'est pas sûr, voir -Wformat-security. Il existe également des outils plus avancés qui garantissent qu'un appel de printfest sûr, même avec des chaînes de format fournies par l'utilisateur, et ils peuvent même vérifier que vous passez le bon nombre et le bon type d'arguments à printf. Par exemple, pour Java, il existe Google's Error Prone et Checker Framework .

Ce sont des conseils mal avisés. Oui, si vous avez une chaîne d'exécution à imprimer,

printf(str);

est assez dangereux et vous devriez toujours utiliser

printf("%s", str);

au lieu de cela, car en général, vous ne pouvez jamais savoir si strpeut contenir un %signe. Cependant, si vous avez une chaîne constante au moment de la compilation , il n'y a rien de mal avec

printf("Hello, world!\n");

(Entre autres choses, c'est le programme C le plus classique de tous les temps, littéralement du livre de programmation C de Genesis. Donc, quiconque désapprouve cet usage est plutôt hérétique, et moi, je serais quelque peu offensé!)

Un aspect plutôt désagréable de printfest que même sur les plates-formes où la lecture de la mémoire parasite ne peut causer que des dommages limités (et acceptables), l'un des caractères de formatage %n, fait que l'argument suivant est interprété comme un pointeur vers un entier inscriptible, et provoque le nombre de caractères sortis jusqu'à présent pour être stockés dans la variable ainsi identifiée. Je n'ai jamais utilisé cette fonctionnalité moi-même, et parfois j'utilise des méthodes légères de style printf que j'ai écrites pour n'inclure que les fonctionnalités que j'utilise réellement (et n'inclut pas celle-là ou quoi que ce soit de similaire) mais alimentant les chaînes de fonctions printf standard reçues provenant de sources non fiables peuvent exposer des failles de sécurité au-delà de la capacité de lire un stockage arbitraire.

Puisque personne ne l'a mentionné, j'ajouterais une note concernant leurs performances.

Dans des circonstances normales, en supposant qu'aucune optimisation du compilateur ne soit utilisée (c'est-à-dire en printf()fait des appels printf()et non fputs()), je m'attendrais printf()à être moins efficace, en particulier pour les longues chaînes. En effet, printf()il faut analyser la chaîne pour vérifier s'il existe des spécificateurs de conversion.

Pour confirmer cela, j'ai effectué quelques tests. Les tests sont effectués sur Ubuntu 14.04, avec gcc 4.8.4. Ma machine utilise un processeur Intel i5. Le programme testé est le suivant:

#include <stdio.h>
int main() {
    int count = 10000000;
    while(count--) {
        // either
        printf("qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM");
        // or
        fputs("qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM", stdout);
    }
    fflush(stdout);
    return 0;
}

Les deux sont compilés avec gcc -Wall -O0. Le temps est mesuré à l'aide de time ./a.out > /dev/null. Ce qui suit est le résultat d'une exécution typique (je les ai exécutés cinq fois, tous les résultats sont dans les 0,002 secondes).

Pour la printf()variante:

real    0m0.416s
user    0m0.384s
sys     0m0.033s

Pour la fputs()variante:

real    0m0.297s
user    0m0.265s
sys     0m0.032s

Cet effet est amplifié si vous avez une très longue corde.

#include <stdio.h>
#define STR "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM"
#define STR2 STR STR
#define STR4 STR2 STR2
#define STR8 STR4 STR4
#define STR16 STR8 STR8
#define STR32 STR16 STR16
#define STR64 STR32 STR32
#define STR128 STR64 STR64
#define STR256 STR128 STR128
#define STR512 STR256 STR256
#define STR1024 STR512 STR512
int main() {
    int count = 10000000;
    while(count--) {
        // either
        printf(STR1024);
        // or
        fputs(STR1024, stdout);
    }
    fflush(stdout);
    return 0;
}

Pour la printf()variante (exécutée trois fois, réel plus / moins 1,5 s):

real    0m39.259s
user    0m34.445s
sys     0m4.839s

Pour la fputs()variante (exécutée trois fois, réel plus / moins 0,2 s):

real    0m12.726s
user    0m8.152s
sys     0m4.581s

Remarque: Après avoir inspecté l'assembly généré par gcc, j'ai réalisé que gcc optimise l' fputs()appel à un fwrite()appel, même avec -O0. (L' printf()appel reste inchangé.) Je ne suis pas sûr que cela invalidera mon test, car le compilateur calcule la longueur de la chaîne fwrite()au moment de la compilation.

printf("Hello World\n")

compile automatiquement vers l'équivalent

puts("Hello World")

vous pouvez le vérifier en désassemblant votre exécutable:

push rbp
mov rbp,rsp
mov edi,str.Helloworld!
call dword imp.puts
mov eax,0x0
pop rbp
ret

en utilisant

char *variable;
... 
printf(variable)

entraînera des problèmes de sécurité, n'utilisez jamais printf de cette façon!

votre livre est donc correct, l'utilisation de printf avec une variable est obsolète mais vous pouvez toujours utiliser printf ("ma chaîne \ n") car elle deviendra automatiquement put

Pour gcc, il est possible d'activer des avertissements spécifiques pour vérifier printf()et scanf().

La documentation gcc indique:

-Wformatest inclus dans -Wall. Pour plus de contrôle sur certains aspects de la forme de contrôle, les options -Wformat-y2k, -Wno-format-extra-args, -Wno-format-zero-length, -Wformat-nonliteral, -Wformat-securityet -Wformat=2sont disponibles, mais ne sont pas inclus dans -Wall.

Le -Wformatqui est activé dans l' -Walloption n'active pas plusieurs avertissements spéciaux qui aident à trouver ces cas:

• -Wformat-nonliteral vous avertira si vous ne passez pas une chaîne littérale comme spécificateur de format.
• -Wformat-securityvous avertira si vous passez une chaîne qui pourrait contenir une construction dangereuse. C'est un sous-ensemble de -Wformat-nonliteral.

Je dois admettre que l'activation a -Wformat-securityrévélé plusieurs bogues que nous avions dans notre base de code (module de journalisation, module de gestion des erreurs, module de sortie xml, tous avaient des fonctions qui pouvaient faire des choses indéfinies si elles avaient été appelées avec% caractères dans leur paramètre. Pour info, notre base de code a maintenant environ 20 ans et même si nous étions conscients de ce genre de problèmes, nous avons été extrêmement surpris lorsque nous avons activé ces avertissements, combien de ces bogues étaient encore dans la base de code).

En plus des autres réponses bien expliquées avec toutes les préoccupations secondaires couvertes, je voudrais donner une réponse précise et concise à la question posée.

Pourquoi printfun argument unique (sans spécificateurs de conversion) est-il obsolète?

Un printfappel de fonction avec un seul argument en général n'est pas obsolète et n'a pas non plus de vulnérabilités lorsqu'il est utilisé correctement comme vous coderez toujours.

C Les utilisateurs du monde entier, du statut de débutant à celui d'expert en statut, l'utilisent printfpour donner une simple phrase de texte en sortie à la console.

De plus, quelqu'un doit distinguer si ce seul et unique argument est une chaîne littérale ou un pointeur vers une chaîne, ce qui est valide mais généralement pas utilisé. Pour ce dernier, bien sûr, il peut se produire des sorties gênantes ou tout type de comportement non défini, lorsque le pointeur n'est pas correctement défini pour pointer vers une chaîne valide, mais ces choses peuvent également se produire si les spécificateurs de format ne correspondent pas aux arguments respectifs en donnant arguments multiples.

Bien sûr, il n'est pas non plus juste et correct que la chaîne, fournie comme un seul et unique argument, ait des spécificateurs de format ou de conversion, car il n'y aura pas de conversion.

Cela dit, donner un littéral de chaîne simple comme "Hello World!"comme seul argument sans aucun spécificateur de format à l'intérieur de cette chaîne comme vous l'avez fourni dans la question:

printf("Hello World!");

n'est pas du tout obsolète ou « mauvaise pratique » et n'a aucune vulnérabilité.

En fait, de nombreux programmeurs C commencent et ont commencé à apprendre et à utiliser C ou même les langages de programmation en général avec ce programme HelloWorld et cette printfdéclaration comme les premiers du genre.

Ils ne le seraient pas s'ils étaient obsolètes.

Dans un livre que je lis, il est écrit printfqu'avec un seul argument (sans spécificateurs de conversion) est obsolète.

Eh bien, alors je me concentrerais sur le livre ou sur l'auteur lui-même. Si un auteur fait vraiment de telles affirmations , à mon avis, des affirmations incorrectes et même enseigne cela sans expliquer explicitement pourquoi il / elle le fait (si ces affirmations sont vraiment littéralement équivalentes fournies dans ce livre), je considérerais cela comme un mauvais livre. Un bon livre, par opposition à cela, expliquera pourquoi éviter certains types de méthodes ou de fonctions de programmation.

D'après ce que j'ai dit ci-dessus, l'utilisation printfavec un seul argument (une chaîne littérale) et sans aucun spécificateur de format n'est en aucun cas déconseillée ou considérée comme une "mauvaise pratique" .

Vous devriez demander à l'auteur ce qu'il voulait dire par là ou, mieux encore, lui demander de clarifier ou de corriger la section relative pour la prochaine édition ou les empreintes en général.