Newsgroup: it.comp.lang.c++
Titolo: Problemi di sicurezza del C/C++. Risolti?

Ri-ciao a tutti,
tempo fa seguivo i vari problemi di (in)sicurezza dovuti al
bad-programming di molte persone.
Un errore _storico_ e' quello dovuto a "strcpy".
<spiegazione_lampo>
La funzione non faceva un controllo sulle dimensioni dei buffer e cosi'
era possibile 'sfondare' il buffer, arrivare a sovrascrivere l'indirizzo
di ritorno della funzione e fare cosi' in modo che la funzione facesse
ritorno ovunque volessimo.
</spiegazione_lampo>
Mi chiedevo se questo errore fosse stato 'risolto' col passare del
tempo. La funzione "std::strcpy", per esempio, ne e' ancora vulnerabile?
In C (sorry per l'OT) lo e' ancora?
Non ho ancora provato, ma spero di... si'! :)
Perche' secondo me e' il programmatore che deve poter decidere tutto.
Sbaglio?
Grazie,
Karma

 Karma
ciao
    sbirish

 e lo sara' sempre. il problema non e' di strcpy E' di come viene usata.
m'era sfuggito un accento :P
 sbirish

 e lo sara' sempre.
Temevo qualche mr avesse avuto la brillante idea di inserire un
controllo anche nella strcpy. Chissa' come m'e' venuta l'idea...
Saluti,
Karma

 Karma
ciao
    sbirish

 altresì detto buffer overflow.. problema ancora attuale.
Che non è mai stato un problema per i programmatori, per i praticoni invece
qualche volta lo è...
Appesantire del codice con controlli utili a prevenire errori stupidi da
parte di programmatori improvvisati è stupido.
Il bello del C (per parlare di strcpy) è proprio che se ha int a[10] e fai
a[11]=1; non controlla un bel niente...
Quì la sicurezza non c'entra... bisogna imparare a programmare.

 Quì la sicurezza non c'entra... bisogna imparare a programmare.
Anche un programmatore esperto commette errori. In particolare commetterà
errori "stupidi" in quanto maggiormente concentrato sul vero nocciolo del 
problema che sta' risolvendo e non a tutti i piccoli dettagli. :-)
Bye

 Bye
Uno sbirish e chi la fa troppo semplice.

 Sbaglio?
si, sbagli (IMO).
Il programmatore non *deve* decidere tutto; la programmazione e` gia` 
complessa cosi` com'e`, non andiamo a complicarci la vita piu` del 
necessario.
Ci sono delle cose che i computer fanno molto meglio degli uomini: 
controlli sui limiti di array e stringhe, riallocazione di memoria, 
ecc.: facciamole fare a loro.
Nota che in un moderno sistema il programmatore non *puo`* decidere 
tutto: ad esempio, non puo` decidere in quale zona di memoria allocare 
il programma - non puo` decidere (perlomeno non facilmente) in quali 
pagine di memoria allocare i dati, non puo` decidere quando il suo 
processo andra` in esecuzione.
Il problema non e` quindi nel decidere tutto, ma nel decidere *troppo*: 
saper decidere quando usare strutture dati (e linguaggi!) di alto 
livello e` una delle piu` importanti qualita` di un programmatore.
Il tutto IMO, ovviamente.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 Uno sbirish e chi la fa troppo semplice.
Secondo me è semplicistico dire che il C è insicuro, forse la verità fa
male... è un errore di programmazione.

> concordo, specialmente in progetti molto grandi.
Io ho lavorato per oltre quattro anni su progetti di automazione industriale, legati
a processi produttivi 24/24h sia in veste di programmatore che responsabile di
gruppo e di progetto. Ho usato o fatto usare i piu' svariati linguaggi (compreso il C)
a seconda del progetto.  
Gli obiettivi non erano di fare del codice "figo", ma produrre 
- codice corretto
- codice funzionante
- nel minor tempo possibile
- manuntenibile
Bene che ti vada con il C ottieni come segnalazione di segmentation fault nel punto
giusto, ma se succede come il caso che ho descritto precedentemente ti posso
assicurare che inizi a piangere in "greco spinto". 
L'idea di essere chiamato di notte - in veste di responsabile - a far risolvere un 
problema su un impianto non é il massimo. Anche se non sono costretto ad intervenire
personalmente sul codice.
Un fermo macchina puo' costare anche svariate migliaia di euro giusto per gradire.
Personalmente gradisco risolvere i problemi logici e di progettazione piuttosto che fare 
"la scimmia ricerca bug" in un programma :-)
Il C ha il vantaggio di essere un linguaggio molto semplice -- direi "ortogonale" -- ed 
essere allo stesso tempo molto potente, disponibile per almeno il 99% delle 
architetture hardware presenti sul mercato, é veloce ma ha i suoi lati negativi. 
Bye

 Bye
 
Il C è un linguaggio perfetto. Il C++ è un linguaggio perfetto.
Ricordiamoci perchè è nato il C, con quali finalità. E'nato
essenzialmente come linguaggio di sistema, anche se è possibile usarlo
per qualsiasi cosa. La finalità del C in origine era fornire una sorta di
interfaccia portabile al linguaggio macchina, per creare il primo UNIX.
Il C++ è nato con finalità completamente differenti.

 Il C++ è nato con finalità completamente differenti.
Appunto, un S.O. con le stringhe del C++ e i vettori non è il massimo
dell'efficienza... quì forse ha senso il discorso sicurezza... ma non nel
linguaggio "C", sicuramente.
Rispettoso delle idee di tutti gli altri, saluto tutti.
Paolo.

 strcpy)
Tra l'altro presumo che su sistemi di sviluppo "seri" esistano
dei tools per fare questi controlli sul programma in fase di sviluppo.
Io, che quando ho dovuto (sempre cose ludiche, non programmi
industriali) programmare in C++ sotto Win, ho trovato molto utile il
Codeguard del Borland C++ Builder che appunto mi ha permesso di
individuare a run-debug-time una serie di errori (tipicamente typos) che
mi facevano uscire gli indici dagli array, accedere stringhe oltre la
loro lunghezza, etc.etc.
Direi che una cosa di questo tipo e' il compromesso ideale:
mi permette di effettuare controlli senza modificare il codice
e quindi senza appesantire l'eseguibile finale.
ciao,
g.

errori!
Paolo.. io non ho mai parlato di linguaggio insicuro..
Ti garantisco che tuttavia, poter usare std::string in C++ è una manna
dal cielo.
Spesso il C è utilizzato dove l'efficienza _conta_ 
spesso dove l'efficienza conta anche la sicurezza è molto importante..
per capirsi il mio post non voleva incitare all'uso di java o C#, che,
a livello di linguaggio risolvono il problema alla base.. mi tengo ben
alla larga da una affermazione del genere.. come mi son tenuto alla
larga dal dire che il C è un linguaggio non sicuro.
Con un bazooka in mano si ottiene una potenza di fuoco non 
indifferente, il problema è che non sempre i crateri si creano (
soltanto ) nel posto giusto.
ciao
	sbirish

Paolo.
Paolo non era neanche in dubbio il rispetto per le opinioni altrui..
si discute per chiarire le idee.
ciao
 sbirish

 si discute per chiarire le idee.
Ribadisco e approvo!
Ciao.

 larga dal dire che il C è un linguaggio non sicuro.
Discorso apprezzabile e condivisibile, direi che sono soddisfatto della tua
risposta.
Paolo Ferraresi.

 ciao Anto
Ciao e grazie del parere,
Karma

 .. e mi sembra uno degli ottimi motivi per preferire string ad un char*.
ma non mi piacerebbe se un giorno scoprissi che lo standard del C++ non
permettesse piu' di dichiarare un "char *"!
anche se avessi la liberta' di modificare i sorgenti di "string"...
Saluti,
Karma
ps. mi scuso per il ritardo e chiudo l'OT.

 livello e` una delle piu` importanti qualita` di un programmatore.
Questo invece non solo si puo' ma si deve fare: cominciare dalle
librerie standard e valutare a fronte di verifiche prestazionali
l'eventuale necessita' di ricorrere a soluzioni ad hoc.
Ciao,
Nicola

 librerie siano scritti in modo da supportare questo approccio,
[cut]
concordo in toto: l'ottimizzazione va fatta solo *se* e *dove* serve. 
Pero` volevo aggiungere che questo approccio si puo` adottare anche con 
linguaggi che per scelta non consentono ottimizzazioni spinte ma che 
consentono di riscrivere gli hot-spot in un linguaggio piu` performante 
come ad esempio il C.
Un esempio di tali linguaggi e` TCL: ce ne sono anche altri e io sto 
pensando ad uno in particolare, pero` evito di nominarlo altrimenti si 
scatena il solito flame... :-)


 scatena il solito flame... :-)
Il problema e' che il salto di astrazione tra questi linguaggi ed il C
e' troppo alto: nel 2003 devo ancora ricordarmi di decrementare A MANO
i reference count?
Quando "quel linguaggio li'" sara' riscritto in C++, con
un'interfaccia umana tra i due linguaggi, allora effettivamente la
programmazione fara' un salto paragonabile a quello compiuto
dall'assembler ai linguaggi di terza generazione.
Ciao,
Nicola