Perché printf con un singolo argomento (senza specificatori di conversione) è deprecato?

In un libro che sto leggendo, è scritto che printfcon un singolo argomento (senza specificatori di conversione) è deprecato. Si consiglia di sostituire

printf("Hello World!");

con

puts("Hello World!");

o

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

Qualcuno può dirmi perché printf("Hello World!");è sbagliato? È scritto nel libro che contiene vulnerabilità. Quali sono queste vulnerabilità?

printf("Hello World!"); IMHO non è vulnerabile ma considera questo:

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

Se strcapita di puntare a una stringa contenente %sspecificatori di formato, il tuo programma mostrerà un comportamento indefinito (principalmente un arresto anomalo), mentre puts(str)mostrerà semplicemente la stringa così com'è.

Esempio:

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

printf("Hello world");

va bene e non ha vulnerabilità di sicurezza.

Il problema sta con:

printf(p);

dove pè un puntatore a un input controllato dall'utente. È soggetto ad attacchi di stringhe di formattazione : l'utente può inserire specifiche di conversione per assumere il controllo del programma, ad esempio %xper eseguire il dump della memoria o %nper sovrascrivere la memoria.

Nota che puts("Hello world")non è equivalente nel comportamento a printf("Hello world")ma a printf("Hello world\n"). I compilatori di solito sono abbastanza intelligenti da ottimizzare l'ultima chiamata per sostituirla puts.

Oltre alle altre risposte, printf("Hello world! I am 50% happy today")c'è un bug facile da creare, che potenzialmente causa ogni sorta di brutti problemi di memoria (è UB!).

È solo più semplice, più facile e più robusto "richiedere" ai programmatori di essere assolutamente chiari quando vogliono una stringa letterale e nient'altro .

Ed è questo che printf("%s", "Hello world! I am 50% happy today")ti prende. È del tutto infallibile.

(Steve, ovviamente non printf("He has %d cherries\n", ncherries)è assolutamente la stessa cosa; in questo caso, il programmatore non è nella mentalità "stringa verbatim"; lei è nella mentalità "stringa formato".)

Aggiungerò solo un po 'di informazioni sulla parte della vulnerabilità qui.

Si dice che sia vulnerabile a causa della vulnerabilità del formato stringa printf. Nel tuo esempio, dove la stringa è hardcoded, è innocua (anche se stringhe hardcoding come questa non sono mai completamente consigliate). Ma specificare i tipi del parametro è una buona abitudine da prendere. Prendi questo esempio:

Se qualcuno inserisce il carattere della stringa di formato nel tuo printf invece di una stringa normale (ad esempio, se vuoi stampare il programma stdin), printf prenderà tutto ciò che può nello stack.

Era (ed è ancora) molto utilizzato per sfruttare i programmi nell'esplorazione di stack per accedere a informazioni nascoste o bypassare l'autenticazione, ad esempio.

Esempio (C):

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

se metto come input di questo programma "%08x %08x %08x %08x %08x\n"

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

Questo indica alla funzione printf di recuperare cinque parametri dallo stack e di visualizzarli come numeri esadecimali riempiti di 8 cifre. Quindi un possibile output potrebbe essere simile a:

40012980 080628c4 bffff7a4 00000005 08059c04

Vedi questo per una spiegazione più completa e altri esempi.

La chiamata printfcon stringhe di formato letterali è sicura ed efficiente ed esistono strumenti per avvisarti automaticamente se la tua invocazione di printfstringhe di formato fornite dall'utente non è sicura.

Gli attacchi più gravi printfsfruttano l' %nidentificatore di formato. A differenza di tutti gli altri specificatori di formato, ad esempio %d, %nscrive effettivamente un valore in un indirizzo di memoria fornito in uno degli argomenti di formato. Ciò significa che un utente malintenzionato può sovrascrivere la memoria e quindi potenzialmente assumere il controllo del programma. Wikipedia fornisce maggiori dettagli.

Se chiami printfcon una stringa di formato letterale, un utente malintenzionato non può %nintrodurne una nella stringa di formato e sei così al sicuro. In effetti, gcc cambierà la tua chiamata printfin una chiamata a puts, quindi non c'è nessuna differenza (prova questo eseguendo gcc -O3 -S).

Se si chiama printfcon una stringa di formato fornita dall'utente, un utente malintenzionato può potenzialmente %nintrodurne una nella stringa di formato e assumere il controllo del programma. Il tuo compilatore di solito ti avvertirà che il suo non è sicuro, vedi -Wformat-security. Esistono anche strumenti più avanzati che assicurano che una chiamata di printfsia sicura anche con le stringhe di formato fornite dall'utente e potrebbero persino verificare che tu passi il numero e il tipo di argomenti corretti a printf. Ad esempio, per Java ci sono Google Error Prone e Checker Framework .

Questo è un consiglio fuorviante. Sì, se hai una stringa di runtime da stampare,

printf(str);

è abbastanza pericoloso e dovresti sempre usare

printf("%s", str);

invece, perché in generale non puoi mai sapere se strpotrebbe contenere un %segno. Tuttavia, se hai una stringa costante in fase di compilazione , non c'è niente di sbagliato in questo

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

(Tra le altre cose, questo è il programma in C più classico di sempre, letteralmente dal libro di programmazione in C della Genesi. Quindi chiunque deprecare quell'uso è piuttosto eretico, e io per primo sarei un po 'offeso!)

Un aspetto piuttosto sgradevole printfè che anche su piattaforme in cui le letture vaganti della memoria potrebbero causare solo un danno limitato (e accettabile), uno dei caratteri di formattazione %n, fa sì che l'argomento successivo venga interpretato come un puntatore a un numero intero scrivibile e fa sì che il numero di caratteri emessi fino a quel momento da memorizzare nella variabile così identificata. Non ho mai usato quella funzionalità da solo, ea volte utilizzo metodi leggeri in stile printf che ho scritto per includere solo le funzionalità che uso effettivamente (e non includere quella o qualcosa di simile) ma alimentando le stringhe di funzioni printf standard ricevute da fonti inaffidabili possono esporre vulnerabilità di sicurezza oltre la capacità di leggere archivi arbitrari.

Dato che nessuno l'ha menzionato, aggiungerei una nota sulla loro performance.

In circostanze normali, supponendo che non vengano utilizzate ottimizzazioni del compilatore (cioè printf()chiamate effettivamente printf()e non fputs()), mi aspetto printf()di eseguire in modo meno efficiente, specialmente per stringhe lunghe. Questo perché printf()deve analizzare la stringa per verificare se ci sono specificatori di conversione.

A conferma di ciò, ho eseguito alcuni test. Il test viene eseguito su Ubuntu 14.04, con gcc 4.8.4. La mia macchina utilizza una CPU Intel i5. Il programma in prova è il seguente:

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

Entrambi sono compilati con gcc -Wall -O0. Il tempo viene misurato usando time ./a.out > /dev/null. Quello che segue è il risultato di una corsa tipica (li ho eseguiti cinque volte, tutti i risultati sono entro 0,002 secondi).

Per la printf()variante:

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

Per la fputs()variante:

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

Questo effetto è amplificato se hai una corda molto lunga.

#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;
}

Per la printf()variante (eseguita tre volte, più / meno 1,5 reali):

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

Per la fputs()variante (eseguita tre volte, più / meno 0,2 reali):

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

Nota: dopo aver ispezionato l'assembly generato da gcc, mi sono reso conto che gcc ottimizza la fputs()chiamata a una fwrite()chiamata, anche con -O0. (La printf()chiamata rimane invariata.) Non sono sicuro che ciò invaliderà il mio test, poiché il compilatore calcola la lunghezza della stringa fwrite()in fase di compilazione.

printf("Hello World\n")

compila automaticamente l'equivalente

puts("Hello World")

puoi verificarlo smontando il tuo eseguibile:

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

utilizzando

char *variable;
... 
printf(variable)

porterà a problemi di sicurezza, non usare mai printf in questo modo!

quindi il tuo libro è effettivamente corretto, l'uso di printf con una variabile è deprecato ma puoi ancora usare printf ("la mia stringa \ n") perché diventerà automaticamente put

Per gcc è possibile abilitare avvisi specifici per il controllo printf()e scanf().

La documentazione di gcc afferma:

-Wformatè incluso in -Wall. Per un maggiore controllo su alcuni aspetti del formato di controllo, le opzioni -Wformat-y2k, -Wno-format-extra-args, -Wno-format-zero-length, -Wformat-nonliteral, -Wformat-security, e -Wformat=2sono disponibili, ma non sono inclusi nel -Wall.

L' opzione -Wformatabilitata all'interno -Walldell'opzione non abilita diversi avvisi speciali che aiutano a trovare questi casi:

• -Wformat-nonliteral avviserà se non si passa una stringa letterale come specificatore di formato.
• -Wformat-securityavviserà se passi una stringa che potrebbe contenere un costrutto pericoloso. È un sottoinsieme di -Wformat-nonliteral.

Devo ammettere che l'abilitazione ha -Wformat-securityrivelato diversi bug che avevamo nella nostra base di codice (modulo di registrazione, modulo di gestione degli errori, modulo di output xml, tutti avevano alcune funzioni che potevano fare cose indefinite se fossero stati chiamati con caratteri% nel loro parametro. Per informazioni, la nostra base di codice ha ora circa 20 anni e anche se eravamo a conoscenza di questo tipo di problemi, siamo rimasti estremamente sorpresi quando abbiamo abilitato questi avvisi di quanti di questi bug erano ancora nella base di codice).

Oltre alle altre risposte ben spiegate con tutte le preoccupazioni secondarie trattate, vorrei dare una risposta precisa e concisa alla domanda fornita.

Perché printfcon un singolo argomento (senza specificatori di conversione) è deprecato?

Una printfchiamata di funzione con un singolo argomento in generale non è deprecata e non presenta vulnerabilità se usata correttamente, come sempre si codifica.

C Gli utenti di tutto il mondo, dallo status principiante all'esperto dello stato usano printfquesto modo per fornire una semplice frase di testo come output alla console.

Inoltre, Qualcuno deve distinguere se questo unico argomento è una stringa letterale o un puntatore a una stringa, che è valida ma comunemente non utilizzata. Per quest'ultimo, ovviamente, possono verificarsi output scomodi o qualsiasi tipo di comportamento indefinito , quando il puntatore non è impostato correttamente per puntare a una stringa valida ma queste cose possono verificarsi anche se gli specificatori di formato non corrispondono ai rispettivi argomenti dando più argomenti.

Naturalmente, non è nemmeno giusto e corretto che la stringa, fornita come unico argomento, abbia specificatori di formato o conversione, poiché non verrà eseguita alcuna conversione.

Detto questo, dare una semplice stringa letterale come "Hello World!"come unico argomento senza specificatori di formato all'interno di quella stringa come hai fornito nella domanda:

printf("Hello World!");

non è affatto deprecato o " cattiva pratica " né presenta vulnerabilità.

In effetti, molti programmatori C iniziano e hanno iniziato a imparare e utilizzare il C o anche i linguaggi di programmazione in generale con quel programma HelloWorld e questa printfdichiarazione come primi nel suo genere.

Non lo sarebbero se fossero deprecati.

In un libro che sto leggendo, è scritto che printfcon un singolo argomento (senza specificatori di conversione) è deprecato.

Bene, allora concentrerei l'attenzione sul libro o sull'autore stesso. Se un autore sta davvero facendo tali, a mio parere, affermazioni errate e persino insegnando che senza spiegare esplicitamente perché lo sta facendo (se quelle affermazioni sono davvero letteralmente equivalenti fornite in quel libro), lo considererei un brutto libro. Un buon libro, al contrario di quello, spiegherà perché evitare certi tipi di metodi o funzioni di programmazione.

Secondo quanto detto sopra, l'utilizzo printfcon un solo argomento (una stringa letterale) e senza specificatori di formato non è in ogni caso deprecato o considerato "cattiva pratica" .

Dovresti chiedere all'autore cosa intendeva con questo o, meglio ancora, badare a chiarire o correggere la sezione relativa per la prossima edizione o le impronte in generale.