Newsgroup: it.comp.lang.c
Titolo: Dubbio sulle stringhe e vulnerabilità...

Salve ho dei dubbi che potranno sembrarvi banali, ma io non so darmi
risposte:
cosa succede in questi casi?
1.
char stringa[25] = "Questa è una stringa";
strcat(stringa,"Questa è una stringa da aggiungere per superare la
dimensione del buffer istanziato");
----
In questo caso ottengo un buffer overflow exploitabile, immagino, dal
momento che alloco un certo spazio in memoria e concateno successivamente
caratteri che superano la dimensione allocata... Quindi programmando
un'applicazione incorrerei nei problemi di sicurezza cui questo comporta.
Giusto?
----
2.
char stringa[] = "Questa è una stringa";
strcat(stringa,"Questa è una stringa da aggiungere per superare la
dimensione del buffer istanziato");
----
Questa volta non indicando la dimensione dell'array e facendo una strcat()
che succede? Ho un buffer overflow? Il compilatore sa cosa deve fare e mi
gestisce correttamente l'allocazione dei caratteri che concateno? Incorro in
guai di sicurezza? Come devo fare per non incorrere in guai legati alla
sicurezza se non so a priori quanto sarà lunga la stringa?
----
3.
char stringa[] = "Questa è una stringa";            // (A)
static char stringa[] = "Questa è una stringa";   // (B)
----
Quali sono le differenze tra queste 2 differenti dichiarazioni?
----
Scusate se i miei dubbi da neofita sono banali, ma davvero non so dove e
come cercare risposte a questi penso "banali" quesiti.
Grazie!

 sicurezza se non so a priori quanto sarà lunga la stringa?
Devi allocarla dinamicamente:
car stringa[]="questa è una stringa"
char *strimgatemp;
int i=strlen(stringa)+1;
.......
stringatemp=(car *)malloc(i*sizeof(car));
strcpy(stringatemp,stringa);
i=i+strlen(","Questa è una stringa da aggiungere per superare la dimensione
del buffer istanziato, che questa volta non avverà");
stringa=(char *)malloc(i*sizeof(char));
strcpy(stringa,stringatemp);
strcat(stringa,"Questa è una stringa da aggiungere per superare la
dimensione del buffer istanziato, che questa volta non avverà");

 Quali sono le differenze tra queste 2 differenti dichiarazioni?
Prima di tutto sono definizioni, non dichiarazioni.
la prima ha un linkage esterno: ovvero, puoi accedere a 
stringa[] da tutti i moduli del tuo programma, previa dichiarazione con 
"extern char stringa[]".
La seconda ha linkage interno: ovvero, puoi accedere a stringa[] 
soltanto all'interno del modulo nel quale la hai definita.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

Quali sono le differenze tra queste 2 differenti dichiarazioni?
La prima e' una variabile normale, la seconda non puo' essere
modificata dall'esterno della funzione o del modulo (dipende da dove
l'hai dichiarata, se in una funzione o no).
Mox :)

secure_strncat() e ti accorgi della differenza :)
Beh aggiunge solo controlli sulla lunghezza che potrebbero essere
risolti con un piccolo if(...) prima della strcat() /strncat() .
saluti
---
awayzzz <awayzzz at digibel dot org>

Devi allocarla dinamicamente:
oppure mettere un controllo sulle lunghezze  prima della funzione che
potrebbe causare un overflow.
es.
<code>
if(strlen(src) > sizeof(dest)) 
   printf("overflow\n");
else
   ...
</code>
Saluti
--- 
awayzzz <awayzzz at digibel dor org>

controllo.
Attenzione, bisogna accordarsi su cosa si intende per
"funzione sicura".  Comunemente si intende una funzione che,
se utilizzata in modo inappropriato dall'utente, non causa
effetti collaterali e/o comportamenti indefiniti. 
Cioe', una funzione in grado di gestire la situazione
d'errore senza causare problemi.
Da questo punto di vista, le funzioni succitate non sono
sicure, perche' non implementano controlli propri.
Il perche' questi controlli non sono stati implementati di
default non e' inspiegabile.  Il C e' un linguaggio che fu
progettato *da* programmatori *per* programmatori.  Questo
voleva dire che si dava per scontato che chi utilizzasse il
linguaggio sapesse bene cosa stesse facendo.  La mancanza di
questi controlli (e di molti altri nel linguaggio standard)
e' uno dei tanti motivi che rende il C un'arma molto potente
e molto pericolosa, ancora oggi.
-- 
The Follet

 materia di sicurezza non e' proprio il primo che passa :)
veramente pare che tale SS (che non conosco assolutamente, mea culpa) 
l'abbia presa pari pari da openbsd...

d'errore senza causare problemi.
Ragionando in questo modo gran parte delle funzioni standard sono
"insicure". 
Senza contare le funzioni che potrebbero causare overflow, gli esempi
di funzioni potenzialmente insicure sono tantissimi. Ad esempio puň
essere insicura una malloc() senza controllo se l'indirizzo restituito
č NULL potrebbe creare effetti collaterali., oppure una system() con
argomento definibile dall'utente. 
La sicurezza di un programma dipende solitamente dal programmatore e
non dal linguaggio. Pertanto penso che sia piů il programmatore a "non
essere sicuro" piuttosto che una funzione, la quale č solo
"potenzialmente insicura", dipende dall'uso che se ne fa.
Saluti 


 "potenzialmente insicura", dipende dall'uso che se ne fa.
be', se prendi il tanto bistrattato i/o del c++ e le sue stringhe, e' 
possibile implementare la lettura sicura di una stringa da utente senza 
preoccuparsi di overflow, buffer etc... il tutto in maniera semplice.
Farlo col C e' piu' complesso, e di sicuro non sarebbe il codice che 
uno studente alle prime armi scriverebbe.
il codice in questione col c++ sarebbe
std::string  s;
std::getline (std::cin, s);
certo, c'e' da pagare il sovraprezzo di allocare la memoria, di gestire 
le eccezioni, ma sono proprio queste features a dare la sicurezza, 
voluta o meno che sia, ma credo che anche chi ha appena iniziato col 
c++ possa comprendere cosa fa il codice sopra.
Il tutto senza voler scatenare guerre di religione, solo per dire che 
anche il linguaggio scelto ha la sua parte nella sicurezza di un 
programma

 stringa=(char *)malloc(i*sizeof(char));
Questo non puoi  farlo. "stringa" e` un'array di char,  non puo` fare da
lvalue.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Windows /win'dohz/ n. : thirty-two  bit extension and graphical shell to
a sixteen  bit patch to an  eight bit operating system  originally coded
for a  four bit microprocessor  which was  written by a  two-bit company
that can't stand a bit of competition.

non dal linguaggio. 
Non e' vero, o meglio, non e' vero che dipende SOLO dal
programmatore e non dal linguaggio.
Un linguaggio puo' offrire dei controlli che aiutano il
programmatore nello scrivere programmi sicuri, ma in
linguaggio in se' e' poco sicuro.
-- 
The Follet

 lvalue.
Giusto, basta sostituire la diciarazione
car *stringa="Questa è una stringa"
Ciao

"insicure". 
Infatti.
La funzione dev'essere potente e veloce. La sicurezza la implementa il
programmatore dove serve.
Non ha senso avere una strcat() che si mette a fare chissa' quali
controlli se sei sicuro che la stringa 2 conterra' la 1.
Mentre se devi fare I/O dall'esterno devi provvedere a controllare.
Il C e' come un coltello da cucina: non e' per niente sicuro perche'
e' facilissimo tagliarsi, pero' e' pratico e veloce. Se ci mettessi
tutto un sistema di protezioni non sarebbe piu' un coltello ma un
robot da cucina. Funzionerebbe lo stesso, ma per altri scopi.
Il prezzo della potenza e' della velocita' e' appunto questa mancanza
di sicurezza se non si mette il programmatore (quello che usa il
coltello nella metafora) non fa' attenzione.
La metafora non e' mia, ma non vi dico di chi e' :)  Molti di voi
probabilmente sanno chi e' l'autore e se non lo sanno non si sono
letti un libro veramente buono sul C :P
Mox.