Vulnerabilità critica su Glibc mette a rischio sistemi Linux: rilasciato il fix

[adapter]

Originariamente inviato da Pier2204

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...

[Pier2204]

Originariamente inviato da adapter

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...

..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...

[adapter]

Originariamente inviato da Pier2204

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...


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...

[WarDuck]

Originariamente inviato da pabloski

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.

[t0mcat]

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.

[rokis]

Originariamente inviato da adapter

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...

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

[rokis]

Originariamente inviato da Tedturb0

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.
Meglio vivere nell'oscurita!

Addirittura in c..o??? Mi sa che brucia più il tuo che il loro

[adapter]

Originariamente inviato da rokis

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

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....

[GTKM]

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.

[fano]

Originariamente inviato da GTKM

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-Pro...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...

Originariamente inviato da GTKM

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/tre.../src/Compilers
(anche quello Visual Basic .NET a quanto pare).

Originariamente inviato da GTKM

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
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

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...

Originariamente inviato da GTKM

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...).

[pabloski]

Originariamente inviato da WarDuck

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 ).

Originariamente inviato da WarDuck

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?

[t0mcat]

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!

[GTKM]

Originariamente inviato da t0mcat

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!

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.

[t0mcat]

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.

[GTKM]

Originariamente inviato da t0mcat

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).

[pabloski]

Originariamente inviato da GTKM

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.

[t0mcat]

Originariamente inviato da GTKM

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.

[battilei]

Originariamente inviato da fano

Sono gli stessi che hanno scritto il C che, evidentemente, non sapevano usare le stringhe:
http://www.tldp.org/HOWTO/Secure-Pro...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
Ad ognuno il suo.

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

e il compilatore del compilatore in cosa è scritto ?

[GTKM]

Originariamente inviato da t0mcat

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?

[fano]

Originariamente inviato da battilei

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
Ad ognuno il suo.

A me purtroppo tocca usarlo per lavoro pensa te

Originariamente inviato da battilei

e il compilatore del compilatore in cosa è scritto ?

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