Vulnerabilità codice C

[dany1900]

Salve vorrei sapere secondo voi che tipo di vulnerabilità ha questo codice C e se avete qualche consiglio su come fare per toglierla io stavo pensando al buffer overflow però vorrei piu info possibili

char buf[1024];
int i = 0;
char ch;
while((ch = getchar()) != ‘\n’) {
 if(ch == -1) break;
 buf[i++] = ch;
}

[WarDuck]

Il codice si commenta da solo diciamo.

Si, è presente una vulnerabilità di tipo buffer overflow.

Se sai cosa è il buffer overflow, allora sai anche qual è il problema di quel codice e come evitarlo .

Se ti serve altro siamo qui.

[lorenzo001]

Devi comunque controllare che i non raggiunga 1024

[dany1900]

Diciamo non sono molto pratico,stavo leggendo del buffer overflow e ho pensato che potrebbe essere questo il caso,come lo modifichereste voi quel codice per evitarlo? la domanda era appunto questa

[das]

char buf[1024];
int i = 0;
char ch;
while((ch = getchar()) != ‘\n’) {
 if(ch == -1) break;
 buf[i++] = ch;
 if (i==1023)break; //<<---
}

oppure a tuo piacimento:

char buf[1024];
int i = 0;
char ch;
while((ch = getchar()) != ‘\n’) {
 if(ch == -1) break;
 buf[i++] = ch;
 if (i==1023)i=0; //<<---
}

[gianmpu]

Le soluzioni proposte però sono entrambe non corrette. Infatti quando i vale 1022, l'istruzione buf[i++] porta i a 1023, quindi nella prima soluzione si esce prima del dovuto. La seconda, invece, riportando i a 0 elimina il buffer overflow, ma introduce la sovrascrittura dei primi caratteri del buffer e non è detto che questo sia un comportamento desiderato

[lorenzo001]

Io direi

char buf[1024];
int i = 0;
char ch;
while((ch = getchar()) != ‘\n’) {
    if((ch == -1) || (i == 1024)) break;
    buf[i++] = ch;
}

[dany1900]

perche non riesco a farlo girare? tramite una printf volevo vedere cosa accade..ma non riesco a compilarlo..volevo simulare un po il tutto ma sto trovando un po di problemi

Praticamente l errore principale (e unico?) di quel codice è che i poteva superare il 1023 giusto?

[GTKM]

Originariamente inviato da dany1900

perche non riesco a farlo girare? tramite una printf volevo vedere cosa accade..ma non riesco a compilarlo..volevo simulare un po il tutto ma sto trovando un po di problemi

Praticamente l errore principale (e unico?) di quel codice è che i poteva superare il 1023 giusto?

Il problema principale era che non facevi un controllo sulla posizione dell'indice dell'array durante l'esecuzione del ciclo (il che significa, in pratica, che, ad un certo punto, l'array si sarebbe riempito e "saresti andato oltre").

Per risolverlo, appunto, è sufficiente la soluzione suggerita da lorenzo001; analoga situazione se, al posto del while, usassi un for.

[lorenzo001]

Originariamente inviato da dany1900

perche non riesco a farlo girare?

Cioè? Cosa fai? Cosa succede?

[Gimli[2BV!2B]]

Solitamente, usando poi il buffer come stringa C standard, metto sempre il terminatore:

char buf[1024];
int i = 0;
char ch;
while((ch = getchar()) != ‘'\n’) {
    if((ch == -1) || (i == 1023)) break;
    buf[i++] = ch;
}
buf[ i ] = '\0';

[GTKM]

Originariamente inviato da Gimli[2BV!2B]

Solitamente, usando poi il buffer come stringa C standard, metto sempre il terminatore:

char buf[1024];
int i = 0;
char ch;
while((ch = getchar()) != ‘'\n’) {
    if((ch == -1) || (i == 1023)) break;
    buf[i++] = ch;
}
buf[ i ] = '\0';

Devi farlo sempre
Non inserire il carattere terminatore è uno degli errori che molti fanno, con le conseguenze del caso... L'altro è fare a cazzotti con l'aritmetica dei puntatori

[WarDuck]

Il concetto è quello che devi sempre controllare di non star scrivendo oltre la dimensione del buffer.

Io lo scriverei così:

#define BUFFER_SIZE 1024

char buf[BUFFER_SIZE];
int i;
char ch;

for (i = 0; i < BUFFER_SIZE-1; i++) {
    ch = getchar();

    if (ch == '\n' || ch == -1) break;

    buf[i] = ch;
}

buf[i] = '\0';

E' immediato capire che questo codice è corretto, e scrivendolo in questo modo il compilatore ti può venire in aiuto se attivi i flags -Wall -Wextra, segnalandoti eventuali anomalie sugli indici a tempo di compilazione.

Nota che questo non è sempre vero e devi avere un compilatore abbastanza recente.

[GTKM]

Originariamente inviato da WarDuck

Il
concetto è quello che devi sempre controllare di non star
scrivendo oltre la dimensione del buffer.

Io lo scriverei così:

#define BUFFER_SIZE 1024

char buf[BUFFER_SIZE];
int i;
char ch;

for (i = 0; i < BUFFER_SIZE-1; i++) {
    ch = getchar();

    if (ch == '\n' || ch == -1) break;

    buf[i] = ch;
}

buf[i] = '\0';

E' immediato capire che questo codice è corretto, e scrivendolo in
questo modo il compilatore ti può venire in aiuto se attivi i flags
-Wall -Wextra, segnalandoti eventuali anomalie sugli indici a tempo di
compilazione.

Nota che questo non è sempre vero e devi avere un compilatore abbastanza
recente.

Concordo, questo è il modo corretto di scrivere quel codice.

[lorenzo001]

Se non è espressamente indicato, quel buffer non è detto che sia usato come stringa terminata con NULL.

Quindi non è strettamente necessario usare il NULL terminale.

[vbextreme]

#define BUFFER_SIZE 1024

char buf[BUFFER_SIZE];
int i = 0;

while ( '\n' != (buf[i] = getchar()) && i < BUFFER_SIZE - 1) ++i;
buf[i] = '\0'

ma così era brutto?

[lorenzo001]

No, ma chi impara comincia con del codice più semplice e comprensibile possibile ...

Se si vuole fare la gara a chi ce l'ha più criptico (il codice), allora è un'altra storia ...

[Gimli[2BV!2B]]

Non solo chi comincia... se mi ritrovassi a cercare un problema in una riga così, alle sei di sera di un venerdì dopo sei anni che l'ho scritta (cambiando stile, linguaggi, perdendo diottrie) mi darei dello scemo con trasporto...

(ogni riferimento a fatti realmente accaduti è puramente casuale)

[GTKM]

Codice scritto in maniera criptica è sempre un problema, sia per chi inizia, sia per chi ha 30 anni di carriera alle spalle.
La leggibilità del codice, per quanto mi riguarda, deve essere un punto fondamentale nella realizzazione di qualsivoglia progetto, anche perché rende più facili modifiche future ed eliminazione dei bug.

Ad esempio, nel famoso testo "Linguaggio C" di K&R si pone attenzione proprio sul non abusare della possibilità offerta dal linguaggio di "scrivere il meno possibile".