Bug nel JavaScript di Firefox: dati sensibili a rischio

No, questo problema potrebbe presentarsi in maniera molto più "semplice" e "meschina": basta un banale errore di battitura, ad esempio scrivi 100000000 invece di 10000000 (ti "scappa" uno zero) nel ciclo che legge "qualcosa" (una certa quantità di dati) e la copia su un buffer (una certa porzione di memoria, sufficientemente grande per contenere un certo numero di dati dello stesso tipo e "grandezza" grande 10000000 di "posti", rileggendo il codice non te ne accorgi, per il compilatore non è un errore (a meno che non usi un linguaggio di programmazione che tiene conto di questi dettagli, ma a volte, per questione di prestazioni/ottimizzazione/motivi vari, si usano linguaggi con meno "controlli" di questo tipo, come il C - linguaggio in cui ti ricordo che è scritto tutto il kernel di Linux, ma non solo: la scelta del linguaggio di per sé non è un errore) e viene creato un eseguibile che funziona correttamente pur avendo un bug potenzialmente molto pericoloso. Potresti fare moltissimi test con input plausibilmente reali e non accorgerti del bug. Il programma in questione potrebbe essere usato per molto tempo senza che si presenti nessun problema, perchè magari in tutti i casi reali che si possono presentare ti serviranno sempre meno di 10000000 di "posti"; però, se un input creato appositamente va a scrivere più di 10000000 di "elementi" nel buffer, verranno sporcate aree di memoria vicine, le quali potrebbero contenere dei dati più o meno importanti, che verrebbero corrotti, oppure delle istruzioni, che diventerebbero prive di senso o peggio ancora maligne, e solo allora ti accorgeresti del bug!

Il mio è un esempio MOLTO elementare e semplicistico, ma spero che basti a mostrarti come possa essere semplice produrre un bug senza che il tuo stile di programmazione sia necessariamente cattivo: può capitare a tutti di sbagliare, e basta veramente poco, anche una svista, per fare insorgere dei problemi tutt'altro che irrilevanti. Alcuni anni fa (non ricordo esattamente quanti) la NASA si è persa per strada (ovvero nel vuoto cosmico) una costosissima sonda per un ";" (o forse una "," ma cambia poco) fuori luogo in un certo ciclo, che ne stravolgeva il funzionamento. E pensare che quello era un software "mission critical", di quelli che non possono permettersi bug e vengono sottoposti a controlli e test lunghissimi, severissimi e rigorosissimi, molto più di quelli che occorrono per un software destinato a un'utenza più o meno domestica...




Vedi sopra: uno stile di programmazione impeccabile non ti pone al riparo da possibili errori, statisticamente più è lungo il codice, più aumenta la probabilità che ci siano dei bug, e un banalissimo errore di battitura può trasformarsi in un gravissimo errore di logica.

Per tornare un po' in topic con i bug di FF, tornando indietro di alcuni post si parlava di un bug che causa memory leakage: si tratta un problema grave, potenzialmente molto pericoloso per il corretto funzionamento del sistema (ruba inutilmente memoria a tutti gli altri processi) e sicuramente fastidioso, molto difficile da correggere, tant'è che ad oggi non è stata rilasciata una patch. Molto probabilmente, per correggere questo bug sarà necessaria una profonda revisione di TUTTO il codice sorgente, riga per riga, alla ricerca dei puntatori gestiti male. Non so che dimestichezza hai con la programmazione, si tratta di un problema che sorge nella gestione dinamica della memoria, che è molto importante nei programmi ma altrettanto difficile e potenzialmente pericolosa, poichè è facilissimo compiere degli errori, basta una piccolissima dimenticanza. Ti faccio un esempio:
supponi di voler creare una struttura dati dinamica per usare solo la memoria che serve quando serve, userai un puntatore e scriverai istruzioni del tipo

punt = nuova_struttura_dinamica;

questa struttura è associata al puntatore e si può raggiungere solo con punt; a questo punto userai punt, farai anche altre cose che non lo riguardano, e quando non ti servirà più (o peggio, dovrai riutilizzarlo) potresti scrivere qualcosa (istruzione comunque corretta) del tipo

punt = null;

oppure (situazione più facile da verificarsi che provocherà il leakage)

punt = altra_struttura_dinamica;

dimenticando di cancellare nuova_struttura_dinamica (il nome può ingannare: in realtà non ha un nome e si può usare solo tramite punt o un altro puntatore che venga assegnato alla struttura puntata da punt - cioè punt2 = punt). A questo punto non puoi più accedere a nuova_struttura_dinamica, che non è una variabile ma un area di memoria accessibile solo tramite un puntatore, e diventa impossibile rilasciare la risorsa che non serve più (cioè, quell'area di memoria è irrimediabilmente persa fino al termine dell'esecuzione del programma).

A prima vista potrebbe sembrare un errore grossolano, però bisogna considerare che i puntatori sono un po' complicati da gestire, soprattutto quando entrano in gioco gli oggetti e strutture dinamiche complesse, e quando aumenta il numero di indirezioni (un puntatore che punta a un puntatore che punta a ... che punta a un'area di memoria dinamica), per cui il fatto che in FF ci sia questo grave problema e che la soluzione riguarderà una larga parte del codice non vuol dire che FF sia stato scritto male o con un cattivo stile di programmazione (i parametri per giudicare la bontà di uno stile di programmazione sono altri). Il problema è che più un sw è lungo e complesso, più è probabile che contenga bug.

PS: non è che io voglia difendere MS a tutti i costi, le schermate blu frequenti davano fastidio anche a me, certe scelte - commerciali, architetturali,... - non mi hanno fatto fare i salti di gioia. Cerco comunque di essere obiettivo: tutti possono sbagliare, qualunque prodotto ha i suoi pregi e i suoi difetti.

Dipende, a volte gli errori più banali sono quelli più difficili da scovare (vedi ";" che fa mancare l'orbita di un pianeta a una sonda della NASA).

Bye.

A proposito di bug

Azz, non so se lo avete notato, ma ce n'è uno "nuovo" nel parser dei post sul sito: tutto ciò che è compreso tra il primo e l'ultimo "quote" viene inglobato in un'unica citazione. Sul forum non mi pare che succeda...

X la redazione: non ci si può fare nulla? (sempre che non ci stiate già lavorando )

lunedì erano già in programma un po' di interventi...tra cui anche il parser dei commenti da sito

ciao

trattandosi di un file l'ho uploadato ora fatemi sapere

io penso che con l'andare avanti con il tempo, bisogna sempre più pensare alla sicurezza del codice oltre che l'efficacia/efficienza...

programmare bene o male lo possono far tutti, fare codice sicuro no...servono approcci mentali, rigorosità e molto altro...cosa che tutti i programmatori dovrebbero avere e non solo alcuni...secondo me abbiamo passato la fase dell'ottimizzazione del codice, ora dobbiamo seriamente passare alla sicurezza del codice, sia a causa della maggior completezza dei linguaggi sia per ragioni proprie di bug ecc...

basta guardare l'approccio di Bernstein, informatevi su Qmail o su djbdns... quello è un approccio verso le prestazioni e verso soprattutto la sicurezza del codice...qmail è sostanzialmente lo stesso dal 1998



e in questo periodo non ci sono stati richiami vari...un esempio di codice scritto con la sicurezza come meta finale

Quello è sparito

Comunque te ne faccio notare un altro minore, che c'è da un po' e non si nota più di tanto: il carattere " ) " accanto a un carattere accentato (forse anche in presenza di virgolette, ho aggiunto uno spazio per sicurezza) viene interpretato come la faccina (il carattere accentato, comunque, non viene alterato); se si aggiunge uno spazio non si verifica (non mi pare che si verifichi sul forum). Poi, tempo fa notavo (non so francamente se succede ancora, e forse succedeva anche sul forum) che chiudendo le parentesi accanto a un "tag" tipo ": rolleyes :" (delimitato dai ":" ) si otteneva un e il codice precedente veniva ignorato, come se il parser valutasse prima le possibili combinazioni tra il carattere " ) " e quelli circostanti (un po' come i compilatori in presenza di operatori di diversa precedenza), invece di "renderizzare" il primo tag buono che incontrava.

Sono dettagli minori (l'ultimo non so se si verifichi ancora, mi è tornato in mente e lo faccio presente), ma visto che siamo in tema faccio il pignolo

Edit - altro piccolo dettaglio: sul sito non compare la scritta "quote:" sopra le citazioni (se sto oltrepassando il limite puoi sempre mandarmi a quel paese credo di essere ai limiti di una sospensione per "molestie" alla redazione )

Ciao

Credo che quel pezzo di codice fosse scritto in Fortran e probabilmente in quella versione non era contemplata la programmazione strutturata (e vai di goto, return et similia), anzi, credo che il problema si sia presentato in uno degli stratagemmi usati per ottenere un ciclo: il ";" fuoriluogo credo tagliasse fuori un numero da un 'istruzione di salto che andava ripetuta; il numero a quel punto perdeva di significato e il compilatore lo ignorava (un po' come se in C scrivessi qualcosa del tipo:
a = b; 100
c = funzione(b);
e il compilatore non mi desse nessun warning; comunque prendi questo discorso con le pinze, personalmente non conosco il Fortran, ricordo qualcosa su quel bug da una lezione di Linguaggi). Il guaio è che più il tuo codice è lungo e complesso e più aumentano le probabilità che un errore elementare, banale, grossolano, intollerabile, e chi più ne ha più ne metta, finisca col mimetizzarsi perfettamente in mezzo a tante istruzioni corrette e diventi difficile da scovare, anche se con un po' d'esperienza si impara a cercare al volo gli errori di battitura più comuni, ma a volte l'occhio (e l'incapacità di prevedere proprio tutto in fase di testing) può ingannare (esempio banale, "#inculde" in fretta potresti leggerlo come "#include" ). Inevitabile comunque che qualche testa sia saltata, insieme a molte coronarie .



Java mi piace, e mi piacciono in particolare le caratteristiche a cui ti riferisci, però non si può mai abbassare la guardia: basta un piccolo bug nel compilatore/interprete che sia e i benefici del linguaggio di alto livello vanno a farsi benedire...

Stai sempre allerta, amico, il bug è sempre in agguato, ci osserva, trama nell'ombra, attende il momento giusto per trapassarti il cuore...

Si, ma anche quel codice dovrebbe avere molti anni (non ricordo esattamente quanti, ma è passato un po' di tempo da quando quella sonda "prese il largo". Le versioni più recenti del Fortran integrano istruzioni per la programmazione strutturata (non so dirti sugli oggetti, ma non mi stupirei più di tanto), e già poco tempo dopo il "boom" del Pascal fu introdotto il RatFor (rational fortran), che consisteva nel Fortran più le istruzioni per la creazione di strutture a blocchi, tradotte nelle istruzioni "normali" prima della compilazione vera e propria. Onestamente non ricordo se quel lancio funesto avvenne prima ancora, ma in ogni caso la programmazione strutturata non era ancora lo standard (tant'è che il basic, più o meno contemporaneo del pascal, ma anche nelle versioni successive, non la contemplava). Il fatto è che in generale si tende a riutilizzare il codice scritto in precedenza (specialmente se funziona bene) e in certi ambiti, sia che si tratti di manutenzione ordinaria, sia di modifiche/aggiunte un po' più corpose, si preferisce evitare un refactoring profondo (ovvero una riscrittura del codice) anche a costo di continuare a usare un linguaggio vecchio e uno stile di programmazione superato, pur di non rischiare di introdurre nuovi bug nelle porzioni di codice dove non ce ne sono (o si può ritenere ragionevolmente che non ce ne siano, non essendosi presentati bug per un periodo sufficiente lungo). Sicuramente questo era vero allora, ma in alcuni casi lo è ancora: ad esempio, il sistema di gestione del database al centro di calcolo dell'Università di Palermo è scritto in PL1 (più vecchio del Pascal) e funziona egregiamente, un refactoring potrebbe costare caro, ma si potrebbe pensare anche a un programma che fa i calcoli di una costruzione (pensa se si trattasse di un ponte, di una centrale elettrica, di un'industria metallurgica: te la sentiresti di rischiare riscrivendo in un altro linguaggio un programma che funziona? certo, se lo devi scrivere ex novo allora il discorso cambia...)



Mi pare dicesse qual cosa del tipo: "Le capacità di un programmatore sono inversamente proporzionali al numero di goto presenti nel programma", ovviamente vale anche per la correttezza e la leggibilità (e di conseguenza, la bravura del programmatore).



Sono d'accordo con te, ma questo è vero fino a un certo punto. Innanzi tutto, così il problema si sposta dal "controllo" esercitato dal programmatore, umano e tutt'altro che infallibile, a quello del compilatore/framework, che è comunque un software e quindi può contenere errori sui quali tu, lavorando ad un livello più alto, non puoi avere nessun controllo (se ti colleghi al sito di Java troverai l'elenco dei bug periodicamente trovati e risolti); è anche vero che così i problemi eventuali possono essere ristretti, localizzati e ridotti nel numero, ma non eliminati del tutto. Poi, quel risultato è ottenuto in parte mediante limitazioni alla libertà del programmatore: ad esempio, Java ti impedisce di gestire direttamente l'allocazione della memoria (intendendo per direttamente la richiesta al sistema operativo di allocarne quanta ne vuoi e più o meno come vuoi: in definitiva lo fa lui), cosa che per un OS è di fondamentale importanza, inoltre non è possibile sovraccaricare gli operatori, limitazione utile da un lato, potenzialmente eccessiva ai fini della scrittura di un OS: in C++, ad esempio, potresti scrivere una tua versione dell'operatore new (o più versioni) per accedere in memoria e gestirne l'allocazione nella maniera più opportuna in determinate circostanze (ma potresti farlo anche con apposite funzioni in C, non potresti farlo in alcun modo in Java). In definitiva, difficilmente il kernel di un OS potrà essere scritto con quei linguaggi; i moduli che poggiano sul kernel, e gli strati superiori, invece si . Salvo situazioni particolari, comunque, lo standard dovrebbe diventare quello per la maggior parte delle applicazioni, con tutti i vantaggi che ciò comporterà. Chissà che non si finisca per spostare i driver in "user space" e scriverli con questi linguaggi (non a breve termine comunque, ci vorrà un po' di tempo per giungere a scenari del genere)...

Ciao

Una figata! Poi il thema di Pather con lo stile iTunes è semplicemente favoloso!!!

Consiglio anche ad altri di provarlo, perché ne vale veramente la pena... .)

Grazie tante!!!