Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/vulnerabilita-critica-su-glibc-mette-a-rischio-sistemi-linux-rilasciato-il-fix_61015.html

Google e Red Hat hanno scoperto in maniera indipendente una vulnerabilità di sicurezza introdotta su un aggiornamento della libreria glibc del 2008

Click sul link per visualizzare la notizia.

Vecchia e attiva da parecchi anni, la vulnerabilità è stata scoperta da Google e Red Hat e divulgata solamente lo scorso martedì dopo essere stata corretta.

Non voglio trollare..ma da profano leggo spesso di queste vulnerabilità, gravi e meno gravi, scoperte adesso ma che erano presenti da molti anni e mi chiedo: non è che le vulnerabilità (che una volta scoperte vengono prontamente sistemate) sono sempre state poche su Linux solo perchè erano in pochi che le cercavano, a dispetto dei "molti occhi" che possono leggere il codice?


Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...

E' stata introdotta nel 2008, è stata scoperta da Google e Red Hat lo scorso anno.. oggi c'è una procedura temporane messa a punto da Google per proteggersi, in quanto la falla è attualmente ancora attiva..

Dal 2008 a oggi sono più di 7 anni, possibile che i 10.000 occhi che osservano il codice non si sono accorti? (slogan dei mille occhi che sento da tempo) chi si è accorto sono 2 Aziende di grosse dimensioni come Google e Red Hat?

Possibile che questa falla presente nella libreria GNU C, collezione di codici open-source utilizzati in svariate applicazioni stand-alone e da parecchie distribuzioni di Linux, incluse quelle pensate per soluzioni embedded o router è passata completamente inosservata per tanti anni?

Chissa che ne pensa Battilei :asd:

Be' di sicuro c'e' meno gente che si legge le glibc rispetto a chesso: python-django.

...che in ogni caso sono sempre di piu' di quelli che _non_possono_ leggere il codice proprietario non disponibile di altri fornitori :P

E' un discorso che non tutti percepiscono: il software non e' figo perche' e' open source bensi' quando tanti ci lavorano liberamente e' figo, quindi deve essere open source.

E' come mysql e postgresql: mysql era open source ma gestito da un solo operatore e quando questo e' stato fatto fuori sono stati (e sono ora) dolori.

Ergo: non e' che se domani MS rilascia i sorgenti (impossibile: chissa' cosa c'e' dentro) improvvisamente diventa sicuro e forkabile. E' sicuro quando sottoposto a molteplici reviews e "dependable" quando ha dietro una community che lo conosce e lo sviluppa.

Mazza ho...:O
Certe notizie per alcuni utenti sono come quando perde la Juve.
Uno ci spera. Così poi può festeggiare....:doh:

Non voglio trollare..ma da profano leggo spesso di queste vulnerabilità, gravi e meno gravi, scoperte adesso ma che erano presenti da molti anni e mi chiedo: non è che le vulnerabilità (che una volta scoperte vengono prontamente sistemate) sono sempre state poche su Linux solo perchè erano in pochi che le cercavano, a dispetto dei "molti occhi" che possono leggere il codice?


Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...

Sì è esattamente così: prima Linux praticamente non lo usava nessuno ora inizia ad essere leggermente più usato dalle grandi aziende e si scopre che è un colabrodo!

Il problema è che le grandi corporation hanno pensato bene di dismettere i loro "veri" OS per affidarsi a Linux perché "è gratis" e il risparmio è stato doppio visto che hanno licenziato il loro intero team di sviluppo (AIX è morto, Solaris è morto, ...)! Peccato che il codice Open Source - in realtà - tra il fatto che sarà codice illeggibile / incomprensibile e tra che nessuno ne ha voglia non viene guardato, ma solo visto!
Lo slogan è "Compila? Dunque funziona!" e via che si mergia!

E` la stessa cosa di OpenSSL era piena di bachi ed era un codice senza senso eppure tutti lo usavano! Qualcuno lo aveva mai guardato?

P.S. A onor del vero anche se Android ha forkato completamente il kernel Linux (e Google ne ha riscritto una buona parte probabilmente) e usa Bionic non è invulnerabile (come Superman :Prrr:), ma NON vulnerabile a questo specifico bug, magari ne avrà chissà quanti altri! Finché si usa C/C++ non esistono software sicuri...

non e' questione di sperarci ... e' risaputo che non esiste un software 100% sicuro

E infatti è risaputo anche che molti, scelgono il più sicuro.
Delle altre "pippe" sulla percentuale di mercato, percentuale di sicurezza, del perché e del percome non interessa nulla di nulla a nessuno.
Quindi mi viene da ridere quando un affezionato ai sistemi Microsoft si fionda su notizie come queste e cercare il suo momento di gloria.

Non voglio trollare..ma da profano leggo spesso di queste vulnerabilità, gravi e meno gravi, scoperte adesso ma che erano presenti da molti anni e mi chiedo: non è che le vulnerabilità (che una volta scoperte vengono prontamente sistemate) sono sempre state poche su Linux solo perchè erano in pochi che le cercavano, a dispetto dei "molti occhi" che possono leggere il codice?


Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...

Basterebbe semplicemente essere obiettivi e accettare l'idea che il software in quanto fatto da esseri umani può essere soggetto ad errori.

L'open source consente di guardare il codice sorgente e scoprire eventuali magagne.

È una possibilità in più, non un obbligo.

Dopodiché c'è chi fa il ricercatore di sicurezza per mestiere, e chi invece scopre un bug per casualità.

Nessuno tipicamente si mette a leggere del codice per cercare degli errori se questi non si manifestano in qualche modo, a meno che appunto tu non sia un ricercatore nel campo della sicurezza.

Sì è esattamente così: prima Linux praticamente non lo usava nessuno ora inizia ad essere leggermente più usato dalle grandi aziende e si scopre che è un colabrodo!

Mostrami le centinaia di falle che lo rendono un colabrodo.


E` la stessa cosa di OpenSSL era piena di bachi ed era un codice senza senso eppure tutti lo usavano! Qualcuno lo aveva mai guardato?

Se non ricordo male, il bug era uno (gravissimo eh, e non mi spiego come sia stato possibile non notarlo per 2 anni).
Codice senza senso, sulla base di quale argomentazione tecnica?

Finché si usa C/C++ non esistono software sicuri...

Finché si scriveranno software, non saranno mai esenti da bug. Il linguaggio utilizzato non c'entra una mazza.

Che poi, un OS, o un componente di basso livello, con che lo vorresti scrivere? Java ( :asd: ).

Mostrami le centinaia di falle che lo rendono un colabrodo.

Se non ricordo male, il bug era uno (gravissimo eh, e non mi spiego come sia stato possibile non notarlo per 2 anni).
Codice senza senso, sulla base di quale argomentazione tecnica?


Io - che sono masochista - il codice dove il bug si trovava l'ho guardato!


Funzione di 1000 righe con codice ripetuto
Migliaia di goto
Macro orrende a dai nomi incomprensibili
if la cui graffa si chiudeva dopo centinai di righe!


Tutto questo faceva sì che il BUG era difficile da trovare appunto perché non si riusciva a comprendere il codice!


Finché si scriveranno software, non saranno mai esenti da bug. Il linguaggio utilizzato non c'entra una mazza.


Certo codice scritto male non esente da bug è possibile scriverlo in qualsiasi linguaggio si usi, ma C/C++ sono unsafe by design è così facile scrivere codice bacato con buffer underrun / underflow che poi permette - chissà come - di scardinare tutta la sicurezza dell'OS fino a chiamare pezzi del kernel...


Che poi, un OS, o un componente di basso livello, con che lo vorresti scrivere? Java ( :asd: ).

No, in Java no... in C# :stordita:
Che non vuol dire far girare l'OS sotto una VM, Cosmos una volta compilato l'IL con il normale compilatore Microsoft viene ricompilato in assembler come fa il C, mantenendo comunque la sicurezza (le Stringhe per dire hanno sempre la dimensione giusta non posso scriverci più di quanto ho allocato) di avere un linguaggio Managed.
E` una sfida complessa, ma che si possa fare è certo, è già stato fatto:

http://joeduffyblog.com/2015/12/19/safe-native-code/

beh, non e' la prima e non sara' neanche l'ultima
non vorrei fare il confronto, che non e' una gara (chi se ne frega) ma dove il codice e' chiuso, spesso manco si sa (e con molti meno dettagli utili a metterci una pezza)

/estiqaatsi mode off

quindi mi stai dicendo che windows phone/mobile e' l'OS piu' sicuro in assoluto :asd:

Siamo su una news che parla di Linux.
Ma se ti fa piacere sentirti dire che, in ambito mobile, un O.S che non si fila praticamente nessuno è sicuro allora te lo dico...:asd:

Rispondo solo a questo perché il delirio non continui...


Certo codice scritto male non esente da bug in qualsiasi linguaggio si usi, ma C/C++ sono unsafe by design è così facile scrivere codice bacato con buffer underrun / underflow che poi permette - chissà come - di scardinare tutta la sicurezza dell'OS fino a chiamare pezzi del kernel...


:rolleyes:

Un linguaggio non può essere sicuro/non sicuro.

Il codice che scrivi può essere codice scritto bene o scritto male.

Dipende da quanto sei in grado di rispettare le best practices e da quanto sei capace di comprendere cosa stai facendo esattamente e perché.

E non risolvi il problema come pensi tu aggiungendo altro codice alla minestra, che è quello che viene fatto con i linguaggi che tu consideri "safe": alla fine si basano su interpreti/compilatori JIT scritti in... C/C++.

Nota bene: devi "fidarti" abbastanza di ciò che fa l'hardware e di ciò che fa il compilatore (che non sono esenti da bug).

È aggiungendo codice su codice che si introducono i bug.

Tutto questo perché? Perché uno "sviluppatore" non è in grado di gestire la memoria correttamente? Dal mio punto di vista vuol dire che non è in grado di fare lo sviluppatore e non dovrebbe farlo.

Un linguaggio non può essere sicuro/non sicuro.

Il codice che scrivi può essere codice scritto bene o scritto male.


Però ci sono linguaggi che offrono strumenti e meccanismi semantici che aiutano a scrivere codice più sicuro. Un programmatore non è una macchina, per cui non bisogna scaricargli addosso tutte le responsabilità sul fronte sicurezza e robustezza.

Esistono linguaggi come Rust, ma purtroppo ( e mi costa dirlo ) la comunità opensource in particolare sembra estremamente refrattaria ad utilizzarli. E' pazzesco dover notare che un software fondamentale come SystemD sia stato scritto ancora nel solito, usato ed abusato C.

Ma come non avevi detto che il market share era una minchiata? Perché non mi pare che quello di linux desktop sia tanto superiore a windows mobile :asd:

Se vabbè stammi bene.
Ci vediamo sulla prossima news simile a questa dove sarai già in mano con la bottiglia pronto a festeggiare.
Ma quanti anni hai?
A no aspè...Ho capito...:rolleyes:

@fano le aziende che usano Linux spendono in doppio rispetto a quelle che usano soluzioni diverse. Il costo di manutenzione, formazione, personale e' enorme.

poi il costo del software non e' la licenza è tutto il resto.

Lasciando stare il numero di applicazioni:
android e' gratis, WP è licenziato.

Ma alla fine il costo di un cellulare android è superiore ai lumia, diventano lentissimi dopo poco. devi stare sempre a fare manutenzione. devi mettere antivirus, devi stare attento a mille attacchi.

Alla fine WP mi costa molto meno

Specie in ambito aziendale (da noi si usano Lumia che sono configurati aziendalmente e sono impenetrabili, se si usassero Android sarebbe pericolossissimo per la sicurezza aziendale, sapendo poi che tutti smanettano e ci mettono quello che vogliono (un WP configurato aziendalmente e' blindatissimo)

E' stata introdotta nel 2008, è stata scoperta da Google e Red Hat lo scorso anno.. oggi c'è una procedura temporane messa a punto da Google per proteggersi, in quanto la falla è attualmente ancora attiva..

Dal 2008 a oggi sono più di 7 anni, possibile che i 10.000 occhi che osservano il codice non si sono accorti? (slogan dei mille occhi che sento da tempo) chi si è accorto sono 2 Aziende di grosse dimensioni come Google e Red Hat?

Possibile che questa falla presente nella libreria GNU C, collezione di codici open-source utilizzati in svariate applicazioni stand-alone e da parecchie distribuzioni di Linux, incluse quelle pensate per soluzioni embedded o router è passata completamente inosservata per tanti anni?

Se leggi al descrizione del bug noterai che si può sfruttare solo in due casi:
a) applicazione che usa libc e che per come è fatta è già vulnerabile ad attacchi man-in-the-middle :read:
b) eseguendo ricerche su domini o DNS controllati dall'aggressore.

In altre parole per "funzionare" devono esserci già altri problemi strutturali di sicurezza belli gravi.

Il fatto che sia passata inosservata così a lungo non è così strano, in compenso una volta notato cosa succedeva si è potuto risalire all'origine del problema e correggerlo.

Per rendere l'idea, bug simili su software closed source vengono corretti molto più tardi (SE vengono corretti) proprio perche gli esperti di sicurezza esterni non hanno accesso ai sorgenti, possono al massimo segnalare che in certe condizioni succede qualcosa
ma proprio in questo caso visto di che precondizioni si trattava, verrebbe considerato un bug a bassa priorità oppure non verrebbe replicato correttamente e si penserebbe ad una segnalazione erronea, lasciandolo li a frollare ancora per anni.

Ad esempio, se ti inalberi per i 7 anni di quel bug, che ne dici dei 19 ANNI che ci ha messo Microsoft per accorgersi di un problema ben più grave (http://www.tripwire.com/state-of-security/latest-security-news/microsoft-plugs-winshock-a-critical-19-year-old-rce-bug/) ?

O per dirla in un altro modo Microsoft ha impiegato quasi il triplo per correggere un problema ben più evidente. ;)

azz ragazzi andateci piano... il tasso di trollaggio su questo thread farà schiantare il forum :D


Io - che sono masochista - il codice dove il bug si trovava l'ho guardato!


Funzione di 1000 righe con codice ripetuto
Migliaia di goto
Macro orrende a dai nomi incomprensibili
if la cui graffa si chiudeva dopo centinai di righe!


Tutto questo faceva sì che il BUG era difficile da trovare appunto perché non si riusciva a comprendere il codice!



Certo codice scritto male non esente da bug è possibile scriverlo in qualsiasi linguaggio si usi, ma C/C++ sono unsafe by design è così facile scrivere codice bacato con buffer underrun / underflow che poi permette - chissà come - di scardinare tutta la sicurezza dell'OS fino a chiamare pezzi del kernel...



No, in Java no... in C# :stordita:
Che non vuol dire far girare l'OS sotto una VM, Cosmos una volta compilato l'IL con il normale compilatore Microsoft viene ricompilato in assembler come fa il C, mantenendo comunque la sicurezza (le Stringhe per dire hanno sempre la dimensione giusta non posso scriverci più di quanto ho allocato) di avere un linguaggio Managed.
E` una sfida complessa, ma che si possa fare è certo, è già stato fatto:

http://joeduffyblog.com/2015/12/19/safe-native-code/
mamma mia una if lunga 200 righe non l'ha mai vista nessuno
http://sources.debian.net/src/glibc/2.21-1/resolv/res_send.c
come dire: "C per me significa Chi Czz Ci Capisce Cualcosa" :D


Tutto questo perché? Perché uno "sviluppatore" non è in grado di gestire la memoria correttamente? Dal mio punto di vista vuol dire che non è in grado di fare lo sviluppatore e non dovrebbe farlo.
Ovvio, poi ognuno avrà le sue competenze

@fano le aziende che usano Linux spendono in doppio rispetto a quelle che usano soluzioni diverse. Il costo di manutenzione, formazione, personale e' enorme.

la fonte è Microsoft ? :D

E infatti è risaputo anche che molti, scelgono il più sicuro.
Delle altre "pippe" sulla percentuale di mercato, percentuale di sicurezza, del perché e del percome non interessa nulla di nulla a nessuno.
Quindi mi viene da ridere quando un affezionato ai sistemi Microsoft si fionda su notizie come queste e cercare il suo momento di gloria.

Ti avevo dato una possibilità ma vedo che non capisci.

Io al contrario tuo mi sento persona "ignorante" quindi pongo una domanda e faccio 2 considerazioni su quanto sento e leggo, non in questa notizia in particolare, ma su quello che ho sempre letto riguardo la sicurezza dei sistemi.
Ad esempio LMCH e Warduck hanno fornito una spiegazione esaustiva riguardo questo particolare Bug e sul perchè possono rimanere non scoperti per anni finchè non si manifestano. Tanto mi basta.
Invece la risposta di Battilei è sempre la stessa come un disco incantato, e si permette di dire che c'è un tasso di trollaggio quando lui non perde occasione...
Scusate.

A proposito, guarda un po da dove scrivo...

https://photos-5.dropbox.com/t/2/AAAy5u51wp-AKM8wojc-cfVw9JnjmYD_-QlOoSWvuOtKEQ/12/499714924/png/32x32/1/_/1/2/schermata2.png/EL78locEGJQqIAIoAg/IpWISfuhJbEXIILxFUZiQM6LVC5s0iKB7pY54otd7tk?size=1600x1200&size_mode=3

Mostrami le centinaia di falle che lo rendono un colabrodo.


Se non ricordo male, il bug era uno (gravissimo eh, e non mi spiego come sia stato possibile non notarlo per 2 anni).
Codice senza senso, sulla base di quale argomentazione tecnica?


Finché si scriveranno software, non saranno mai esenti da bug. Il linguaggio utilizzato non c'entra una mazza.

Che poi, un OS, o un componente di basso livello, con che lo vorresti scrivere? Java ( :asd: ).

Ma lasciali trollare i fanboy di Microzozz.
Tanto loro quando glie lo mettono in c..o grazie agli innumerevoli buchi di windoze non se ne accorgono nemmeno, tanto e' tutto non documentato, chiuso, e le patch arrivano quando microzozz vuole, se arrivano. :sofico:
Meglio vivere nell'oscurita!

Ti avevo dato una possibilità ma vedo che non capisci.

Io al contrario tuo mi sento persona "ignorante" quindi pongo una domanda e faccio 2 considerazioni su quanto sento e leggo, non in questa notizia in particolare, ma su quello che ho sempre letto riguardo la sicurezza dei sistemi.



E io al contrario di te e di Emiliano non mi fiondo come un frustrato su ogni notizia come questa. A festeggiare cosa poi?
Una vulnerabilità ogni anno?
Come ho detto....Mazza oh...Come essere Interisti e festeggiare la Juve che perde una volta all'anno.
Uguale...:asd:

E io al contrario di te e di Emiliano non mi fiondo come un frustrato su ogni notizia come questa. A festeggiare cosa poi?
Una vulnerabilità ogni anno?
Come ho detto....Mazza oh...Come essere Interisti e festeggiare la Juve che perde una volta all'anno.
Uguale...:asd:

..niente da fare. Peccato.

Il frustrato è comparso poco dopo e ha scritto "Ma lasciali trollare i fanboy di Microzozz.
Tanto loro quando glie lo mettono in c..o grazie agli innumerevoli buchi di windoze non se ne accorgono nemmeno"

Ecco questo è quello che chiami frustrato, poi tra l'altro ti ho fatto vedere da dove scrivo, ma vedo che sei de coccio...
Altra cosa , quando mi quoti, metti l'intero discorso, non quotare solo parole a metà, perchè dopo capisco perchè devi cambiare Nickname di continuo...

Il frustrato è comparso poco dopo e ha scritto "Ma lasciali trollare i fanboy di Microzozz.
Tanto loro quando glie lo mettono in c..o grazie agli innumerevoli buchi di windoze non se ne accorgono nemmeno"


Anche tu, ma quanti anni hai?
No perché la cosa diventa preoccupante...

Ecco questo è quello che chiami frustrato, poi tra l'altro ti ho fatto vedere da dove scrivo, ma vedo che sei de coccio...


Bhè allora rivedi un po i tuoi collegamenti prima di postarli...:asd:
http://i64.tinypic.com/2wd14aw.jpg

E io naturalmente quoto quello che mi pare a me, nel rispetto del regolamento e non quello che mi imponi tu.
Naturalmente, non avrai altre risposte, visto il tono con cui ti poni con me.
Stammi bene...E prepara anche tu la bottiglia per la prossima vulnerabilità che verrà scoperta di Linux...:asd:

Però ci sono linguaggi che offrono strumenti e meccanismi semantici che aiutano a scrivere codice più sicuro. Un programmatore non è una macchina, per cui non bisogna scaricargli addosso tutte le responsabilità sul fronte sicurezza e robustezza.


Concordo che semantica e sintassi di un linguaggio possono aiutare lo sviluppatore, ma è l'insieme di linguaggio/compilatore/interprete/runtime che va preso in considerazione.

Il fatto che il linguaggio Java (per dire) si appoggi ad una virtual machine piuttosto che essere compilato nativamente non dipende tanto quanto dal linguaggio Java in se (anche se probabilmente alcune cose puoi farle solo avendo a che fare con un interprete).

Il fatto che l'allocazione dinamica possa essere gestita da un garbage collector piuttosto che da un meccanismo di reference counting semplice, non è strettamente una feature del linguaggio, quanto di implementazione.

Per dire: in C non hai keyword per allocare/deallocare memoria (sfrutti funzioni), in C++ si, in Java ed altri hai solo new, in Python neanche lo vedi.

Dopodiché sono convinto che, come diceva Henry Ford, quello che non c'è non si può rompere.

Sicurezza e robustezza fanno rima con semplicità: più una cosa è semplice è più è facile dimostrare che sia sicura/robusta (e meno avrà problemi).

Dopodiché ovviamente i bug ci saranno sempre e comunque, finché non ci saranno metodi di validazione del codice che siano semplici e che siano in grado di garantirne l'assenza.

oh per tutti gli scenziati che si lamentano "ahhh ma come fanno a non accorgersi di sti bug", guardate che glibc è open source, è lì a disposizione, quindi se volete sporcarvi un po' le mani con 47 milioni di righe di C e 10 milioni di assembly, il vostro prezioso contributo è ben accetto.

yea c'è decisamente da fare refactoring di quel blocco if così luuungo, mattuguarda sto codice procedurale demmerda, vecchio 35 anni e scritto da un pugno di hippie barboni...

ah però, ora che ci penso nessuno obbliga nessuno ad usare software libero, e nessuno è tenuto a doverlo mantenere, perché non è che se un giorno metto una bottiglia d'acqua fuori casa, da quel momento in poi tutti acquisiscono il diritto di attaccare le loro tubature al mio contatore.

nel frattempo attendiamo il vostro fantastico porting della standard library di C... in C#. (onestamente, a leggere sta frase rido da solo davanti al pc come un cretino)

oh, magari, prima di lamentarvi, date anche un singolo contributo al FOSS in generale, non so, nell'arco della vostra vita intera.

poi quando andiamo tutti all'inferno contiamo chi ha dato di più, e i peccatori sconteranno in eterno le loro pene dentro un programma di VR open source, pieno di bug cattivissimi.


:muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro:

Se vabbè stammi bene.
Ci vediamo sulla prossima news simile a questa dove sarai già in mano con la bottiglia pronto a festeggiare.
Ma quanti anni hai?
A no aspè...Ho capito...:rolleyes:

ai ai ai ai ai, vedo che quando messo all'angolo, attacchi sul personale! :eek:
Da te non me lo sarei aspettato :asd:

Ma lasciali trollare i fanboy di Microzozz.
Tanto loro quando glie lo mettono in c..o grazie agli innumerevoli buchi di windoze non se ne accorgono nemmeno, tanto e' tutto non documentato, chiuso, e le patch arrivano quando microzozz vuole, se arrivano. :sofico:
Meglio vivere nell'oscurita!

Addirittura in c..o???:eek: Mi sa che brucia più il tuo che il loro :D :asd:

ai ai ai ai ai, vedo che quando messo all'angolo, attacchi sul personale! :eek:
Da te non me lo sarei aspettato :asd:

Ho iniziato a usare il PC con windows 3.1, e Windows lo uso ancora oggi per lavoro.
Negli ultimi 15 anni però a casa l'ho sostituito con sistemi unix e non mi sono mai pentito della cosa.
Semplicemente, mi fanno ridere a crepapelle quelli che, in notizie come questa, se ne escono con:

"ma come, non dicevate che con OSX/LINUX potevo clikkare dove volevo"?

Ripeto: mi sembra di vedere quelli che sperano in una sconfitta della Juve e poi, una volta all'anno quando effettivamente si verifica, tirano fuori le bandiere e scendono a festeggiare....:asd:

Nel 2016 devo ancora leggere le stesse cose?

Se uno sviluppatore non è in grado di gestire la memoria in C/C++, o non riesce a manipolare delle STRINGHE DI CARATTERI, forse, e dico FORSE, da GLIBC, Kernel ed altre parti delicate dovrebbe allontanarsi al più presto; meglio che vada a scrivere gestionali in Java.

C/C++ sono solo dei linguaggi. Il primo, in particolare, è di una semplicità disarmante: l'intero manuale di Kernighan e Ritchie non arriva a 300 pagine (comprese appendici e indice analitico). Il resto è tutto nelle mani dello sviluppatore. Uno che vuole scrivere codice in C (e magari di sistema) e non mette un '\0' per chiudere la stringa forse è meglio, ripeto, che cambi ambito.
Oppure, tutti i detrattori possono iniziare a fare il porting di librerie e altro in linguaggi migliori: nessuno vi vieta di prendere GLIBC e riscriverla in Python, o di scrivere un compilatore per C# (e voglio vedere quale linguaggio usate) ed usare quest'ultimo.

Poi c'è l'altro problema del codice scritto male, ed anche lì, sarà mica colpa di chi è seduto davanti al monitor? Qualsiasi progetto di grosse dimensioni (aperto, chiuso, vedo-non-vedo) ha delle linee guida di base che DOVREBBERO essere rispettate da chiunque voglia metterci le mani, oltre alle consuete pratiche di buona programmazione (ad esempio, assegnare identificatori che abbiano un senso, e non cose tipo "blckdiqpsa").

Fermo restando che, un giorno, magari qualcuno scoprirà che NESSUN SOFTWARE è esente da bug, qualunque sia lo strumento di sviluppo utilizzato per realizzarlo, indipendentemente dalla licenza con cui è distribuito.

Nel 2016 devo ancora leggere le stesse cose?

Se uno sviluppatore non è in grado di gestire la memoria in C/C++, o non riesce a manipolare delle STRINGHE DI CARATTERI, forse, e dico FORSE, da GLIBC, Kernel ed altre parti delicate dovrebbe allontanarsi al più presto; meglio che vada a scrivere gestionali in Java.

C/C++ sono solo dei linguaggi. Il primo, in particolare, è di una semplicità disarmante: l'intero manuale di Kernighan e Ritchie non arriva a 300 pagine (comprese appendici e indice analitico). Il resto è tutto nelle mani dello sviluppatore. Uno che vuole scrivere codice in C (e magari di sistema) e non mette un '\0' per chiudere la stringa forse è meglio, ripeto, che cambi ambito.


Sono gli stessi che hanno scritto il C che, evidentemente, non sapevano usare le stringhe:
http://www.tldp.org/HOWTO/Secure-Programs-HOWTO/dangers-c.html

Il C è semplice? Se intendi semplice nel senso che c'è poca roba allora sì praticamente esistono puntatori, interi (con nomi tra l'altro confusionari char invece di byte, short che però potrebbe essere uguale ad int, long che potrebbe essere uguale ad int, long long che forse è uguale a long o forse è 64 bit!), array (che sono in realtà la stessa cosa dei puntatori)... le Stringhe nella realtà non sono state veramente implementate sono solo un kludge un array di byte interpretati come caratteri ASCII (ma puoi metterci quello che ti pare anche UTF-8, UTF-16 se vuoi) seguito da uno '\0' che spesso le stesse funzioni per manipolare le stringhe si perdono! Ahh sì ci sono anche le strutture bontà loro e non c'è nient'altro!

Ora mi direte, sono obsolete quelle funzioni? Esistono quelle con la 'n' giusto? Beh a parte che la snprintf() potrebbe nemmeno mettere il tappo se la stringa ospite è troppo corta potrebbe troncare e basta (!) e poi non in un tutte le versioni della LIBC sono presenti quindi per scrivere codice portabile manco dovresti usarle...


Oppure, tutti i detrattori possono iniziare a fare il porting di librerie e altro in linguaggi migliori: nessuno vi vieta di prendere GLIBC e riscriverla in Python, o di scrivere un compilatore per C# (e voglio vedere quale linguaggio usate) ed usare quest'ultimo.


Il compilatore C# è scritto... in C#:
https://github.com/dotnet/roslyn/tree/master/src/Compilers
(anche quello Visual Basic .NET a quanto pare).


Poi c'è l'altro problema del codice scritto male, ed anche lì, sarà mica colpa di chi è seduto davanti al monitor? Qualsiasi progetto di grosse dimensioni (aperto, chiuso, vedo-non-vedo) ha delle linee guida di base che DOVREBBERO essere rispettate da chiunque voglia metterci le mani, oltre alle consuete pratiche di buona programmazione (ad esempio, assegnare identificatori che abbiano un senso, e non cose tipo "blckdiqpsa").


Sei sicuro che queste regole valgano per i progetti Open Source? Forse per il kernel Linux dove c'è un dittatore "benevolo" (?) che controlla ogni commit e son gli piace manda a far in c*lo il poveraccio che ancora gli stava dando una mano :D
Poi OpenSSL era pure un caso molto particolare ci metteva le mani una sola persona (forse perché solo lui ci capiva qualcosa?) e tutto il resto del mondo prendeva quel software come fosse oro colato!

Il C non avendo praticamente "struttura" invita a scrivere "spaghetti code" più di altri linguaggi non essendo ad oggetti, non essendo funzionale... e con la scusa che è un linguaggio super performante fa venire la sindrome degli hacker(s) e fa pensare a qui sviluppa una libreria come OpenSSL che per essere più veloci sarebbe più fico riscriversi la malloc()... bacata tra l'altro :Prrr:

Con un linguaggio più ad alto livello ti concentri sul codice che devi davvero scrivere non sulle menate: questa stringa sarà abbastanza grande? Devo fare return, ma devo anche liberare la memoria... che faccio uso un goto? O faccio la free() direttamente qui? Ops avevo anche un file aperto, fammelo chiudere via! Mmh sto puntatore l'avevo mica rilasciato 1000 righe prendi dentro quei 12 if annidati? Boh e chi lo sa? O il mio capo che scalpita e devo fare in fretta... compila? Dunque funziona (solo sulla macchina di test o anche in produzione per 15 anni poi inizia ad andare in SEGFAULT!).

Questo cose sono inacettabili nel 2016 dai...


Fermo restando che, un giorno, magari qualcuno scoprirà che NESSUN SOFTWARE è esente da bug, qualunque sia lo strumento di sviluppo utilizzato per realizzarlo, indipendentemente dalla licenza con cui è distribuito.

Nulla è esente da bug, ma con il C è più facile creare codice bacato o peggio che invoca il satanico "comportamento non definito"!

P.S.
C# così come Java possono essere compilati anche come codice nativo? Lo sapete vero? Ottieni un vero e proprio .exe / ELF! E` compito del compilatore ottimizzare il codice mantendendo allo stesso tempo la safety dove serve e riuscendo a capire dove più ottimizzarla via (per esempio i bound check in molti casi sono ridondanti, un escape analisys può rilevare che molti oggetti possono essere allocati nello stack rendendo il Garbage Collector molto meno "gonfio", ecc...).

Il fatto che l'allocazione dinamica possa essere gestita da un garbage collector piuttosto che da un meccanismo di reference counting semplice, non è strettamente una feature del linguaggio, quanto di implementazione.

Concordo sul fatto che non ci si possa fermare al linguaggio per stabilire se è "safe" o meno. Tuttavia se il linguaggio manca di meccanismi adeguati, ovviamente tali meccanismi non potranno essere presenti nella relativa implementazione. Un compilatore C non può arbitrariamente implementare il bounds checking sugli array ( e le stringhe ).

Inoltre il tirare in ballo i garbage collectors mi ha fatto venire in mente una cosa. Tempo fa ( molti anni fa ) quello del progetto SeL4 analizzarono la sicurezza degli OS basati su codice managed. La loro conclusione fu che erano certamente un balzo in avanti, ma che la complessità del garbage collector creava un nuovo vespaio pieno di bug.

In sostanza tutti vogliono creare un linguaggio sicuro, ecc... ecc... ma poi c'è chi ci riesce meglio e chi peggio ( Rust per esempio è ben riuscito da questo punto di vista ).


Dopodiché ovviamente i bug ci saranno sempre e comunque, finché non ci saranno metodi di validazione del codice che siano semplici e che siano in grado di garantirne l'assenza.

Non ci piove e penso che nessuno sia tanto presuntuoso da pretendere di poter creare software bug free. Il punto è che bisogna riuscire a ridurne il numero e la severità. Per questo mi meraviglio del fatto che in alcune comunità si usino linguaggi che non offrono granchè in questo senso. Ci sta pure scrivere un OS in C, ma un init system dev'essere scritto per forza in C? E una marea di applicazioni utente pure? A che pro?

io credo non sappiate di cosa state parlando.

comunque è open source, siete tutti benvenuti ad aiutare a mantenere la standard library. tanto sto C che sarà mai, è di una semplicità disarmante!!!!11!!!11! :rolleyes: :rolleyes: :rolleyes:

io credo non sappiate di cosa state parlando.

comunque è open source, siete tutti benvenuti ad aiutare a mantenere la standard library. tanto sto C che sarà mai, è di una semplicità disarmante!!!!11!!!11! :rolleyes: :rolleyes: :rolleyes:

Il linguaggio è di un semplicità disarmante, sì (se conosci la differenza tra semplice e facile vedrai che è vero), che poi molto codice sia scritto col cu*o e, gira e rigira, open o meno, solo chi l'ha scritto (forse) riesce a capirci qualcosa, è un altro discorso (ed è il caso di MOLTI progetti "open"), e non è certo colpa dello strumento, ma di chi lo usa.

conosco bene la distinzione tra semplice e facile, e ritengo C sia nessuno dei due.
torno a ripetermi, visto che tu hai questa manualità con il linguaggio, perché non vai a dare una mano a quelli che, a tuo dire, lo scrivono col culo?

sai, nell'open source c'è sempre tanta gente che si lamenta, ma poca che contribuisce.

conosco bene la distinzione tra semplice e facile, e ritengo C sia nessuno dei due.
torno a ripetermi, visto che tu hai questa manualità con il linguaggio, perché non vai a dare una mano a quelli che, a tuo dire, lo scrivono col culo?

sai, nell'open source c'è sempre tanta gente che si lamenta, ma poca che contribuisce.

Perché non me ne frega una beneamata mazza, e perché per approcciarsi a progetti grossi e del tipo della Glibc ci vuole tempo che non ho.

Guarda che non sono io a dire che grazie all'open source è più facile e veloce risolvere bug, visto che so che, all'atto pratico, saranno 4-5 a (voler) capire e migliorare il codice (per beneficienza).

all'atto pratico, saranno 4-5 a (voler) capire e migliorare il codice (per beneficienza).

Beh no. Se guardi chi ha scoperto la vulnerabilità ( Redhat e Google ) noterai che non lo fanno per beneficenza.

Piuttosto il problema ( che esiste ovunque nel settore hi-tech ) è che si preferisce di non toccare ciò che esiste e funziona. Un auditing come avvenne per Truecrypt ( ad esempio ) è un evento più unico che raro in questo mondo. Ed è chiaro che così i bug restano sepolti per anni. E ovviamente è un discorso che vale pari pari per il software closed, solo che lì non ti dicono da quanti anni quel tale bug dormiva sonni tranquilli in qualche file sorgente.

Perché non me ne frega una beneamata mazza

curioso che non te ne frega una beneamata mazza, però non ti risparmi giudizi tipo "ah ancora nel 2016 la gente scrive codice col culo", per poi defilarti con "eh ma io non ho tempo".

spero ti renda conto che non è un'attitudine molto costruttiva.

Sono gli stessi che hanno scritto il C che, evidentemente, non sapevano usare le stringhe:
http://www.tldp.org/HOWTO/Secure-Programs-HOWTO/dangers-c.html
...

No quelli lo sanno benissimo, e lo hanno imparato legioni di sviluppatori.
E d'altra parte hai spiegato bene i motivi per cui io non mi fiderei mai di un Sistema Operativo scritto da sviluppatori che non hanno dimestichezza con puntatori e tipi come con il pane quotidiano :D
Ad ognuno il suo.


Il compilatore C# è scritto... in C#:
https://github.com/dotnet/roslyn/tree/master/src/Compilers
(anche quello Visual Basic .NET a quanto pare).

e il compilatore del compilatore in cosa è scritto ? :D

curioso che non te ne frega una beneamata mazza, però non ti risparmi giudizi tipo "ah ancora nel 2016 la gente scrive codice col culo", per poi defilarti con "eh ma io non ho tempo".

spero ti renda conto che non è un'attitudine molto costruttiva.

Veramente, io ho detto che nel 2016 ancora devo leggere di sviluppatori che non sanno gestire la memoria, che hanno problemi con le stringhe, e che, in conseguenza delle proprie carenze, attaccano un linguaggio SEMPLICE perché non gli mette dei paletti.
L'ho già scritto in un altro thread, ma comunque, direttamente dal K&R:"...il C preserva la sua filosofia originale, secondo cui i programmatori sanno quello che fanno, e richiede soltanto che le loro intenzioni siano espresse con chiarezza."

Ma ripeto, se, alla luce di tutto ciò, chi ha problemi con puntatori e stringhe si intestardisce a voler scrivere parti "critiche" come librerie di sistema, moduli di kernel, e così via, o è scemo, oppure è solo molto ottimista.

L'altra cosa che ho detto è che c'è molto codice scritto "coi piedi", e questo si sente dire spesso, da più parti, e se ne dà la colpa, ancora una volta, al C. Il punto è che se certi progetti possono essere compresi e gestiti solo dai "fondatori" (perché, ripeto, il codice è scritto male, e magari fa schifo pure la documentazione al seguito) l'essere open source o meno diventa quasi indifferente, perché la comunità, gira e rigira, non interverrà MAI. Infatti, il bug in OpenSSL è rimasto lì per un paio d'anni, così come per anni è rimasta nascosta questa falla nella Glibc.

Ora, posso esprimere queste mie opinioni, o, per farlo, devo prima modificare qualche progetto open? :doh:

No quelli lo sanno benissimo, e lo hanno imparato legioni di sviluppatori.
E d'altra parte hai spiegato bene i motivi per cui io non mi fiderei mai di un Sistema Operativo scritto da sviluppatori che non hanno dimestichezza con puntatori e tipi come con il pane quotidiano :D
Ad ognuno il suo.


A me purtroppo tocca usarlo per lavoro pensa te :cry:


e il compilatore del compilatore in cosa è scritto ? :D

Beh anche il compilatore C... è scritto in C! Lo so che sembra un po' paradosso "come faccio a compilare il compilatore se per compilarlo devo avere già il linguaggio?". Il discorso che da almeno 30 anni su ogni macchina Unix c'è già un compilatore C installato e la nuova versione del compilatore C è scritta con una versione diciamo "semplificata" del C stesso che tutti i compilatori sono in grado di compilare.
Per le prime versioni di C# esisteva un bootstrap compiler (certo scritto in C++!) che era in grado di compilare C# quanto bastava per compilare il compilatore C#.
In generale una linguaggio di programmazione si considera "venuto" quando riesci a scrivere il suo stesso compilatore (è la cosa più complicata che può scrivere in un linguaggio) e con esso compilare se stesso. La compilazione di GCC prevede, appunto, dopo la compilazione la ri-compilazione di se stesso :Prrr:

Mah, spesso il problema risiede nel fatto che rileggere il codice in maniera approfondita e' faticoso in generale e certi difetti non si trovano perche' e' difficile vederli se non si ha idea di cosa andare a cercare. I bug, soprattutto sul codice 'maturo' sono abbastanza nascosti e non e' detto che si palesino anche dopo un'attenta analisi, e questo e' vero in generale per tutti i software.

Fatto sta che questo bug e' stato scoperto dalla community ovvero Google e RedHat, e come al solito la patch e' arrivata molto velocemente. HeartBleed ha avuto un decorso simile.

Strapparsi i capelli e puntare il dito per un bug che e' stato scoperto a dopo un'analisi del codice e non a seguito di attacchi/virus mi sembra eccessivo. Soprattutto se, come spesso avviene in linux, non si ha una 'one point security'

Poi oh, se uno si scandalizza per un bug trovato dopo anni, si scandalizza per l'acqua calda, per un fatto naturale dello sviluppo del software.

Mi trovi d'accordo, il punto è che nessun software è esente da bug, e che in un programma scritto "male" è ancora più difficile trovarli.

Detto ciò, a me interessa ribattere a chi dà ad uno strumento (C/C++) responsabilità che sono esclusivamente del programmatore.
Durante il corso su C, all'università, il nostro docente ci fece scrivere le "nostre" funzioni sulla gestione delle stringhe, prima di usare quelle fornite dalla libreria e ricordo bene come uno dei punti cruciali fosse la verifica tra il numero di caratteri inseriti e la dimensione dell'array, oltre al dover inserire il classico '\0'. Oh, stiamo parlando del primo semestre al primo anno di università.

Non c'è nulla di male nel non volersi sporcare le mani con gestione della memoria, o le stringhe (gestite "alla C"), e quant'altro: basta semplicemente cambiare ambito, e non attaccare il linguaggio per una propria carenza. Tra l'altro, alcuni parlano come se solo GNU/Linux usasse questi strumenti, come se il kernel di Windows fosse scritto in C#, o quello di Mac OS X... :rolleyes:

Anche i programmatori più scafati commettono errori. Se dovessimo pretendere che per usare un certo linguaggio non si dovrebbero generare errori come quelli citati, allora potremmo chiudere tutti baracca e burattini.

Per quanta attenzione, verifiche, e test si possano fare, qualche errore può sempre scappare. E con linguaggi come il C, significa avere spesso a che fare con bug intermittenti, use-after-free, memory leak, etc.: roba da mal di testa nonché "sana" disperazione.

E' per questi motivi che sono state realizzate delle tecnologie che aiutino, in hardware (e dunque molto più velocemente dei controlli generati da compilatori), a individuare qualcuno di questi casi. Intel ha presentato MPX già da tempo, mentre un paio di mesi fa Oracle ha mostrato la sua tecnologia di memory access protection.

Riguardo ai compilatori scritti nello stesso linguaggio: FreePascal (http://freepascal.org) e PyPy (http://pypy.org).