Le password G Suite salvate in chiaro da 14 anni: Google risolve il problema e si scusa

[pabloski]

Originariamente inviato da emiliano84

"purtroppo se si vuole la vera sicurezza bisogna pubblicare i sorgenti" (cit.)

A parte che bisognerebbe chiarire che cosa significa "vera sicurezza". Comunque sia avere i sorgenti non vuol dire che sia possibile realizzare software bug-free.

Non so se avete idea di quant'è complesso un sistema operativo, con quali complessi pezzi di firmware e hardware interagisce ( che sono buggati a loro volta ) e a tutto questo bisogna aggiungere le rogne colossali dovute all'esecuzione concorrente dei task.

Esistono metodologie ingegneristiche che aiutano, ma sono totalmente insufficiente.

Per questo al primo anno d'informatica/ingegneria il prof ti dice "il software bug free non esiste".

Detto questo, è lapalissiano che i sorgenti consentono di trovare i bug più velocemente. Ma parliamo di sorgenti in C, scritti in un linguaggio che sa essere criptico.

C'era un bug in openssl in debian. Rimase lì per anni. Centinaia di programmatori c'avevano messo gli occhi sopra e non l'avevano visto.

Ma ci sono pure bug che si vedono a colpo d'occhio. E che purtroppo si vedono molto meno se il listato è in Assembly invece che in C.

L'analisi dinamica del flusso d'esecuzione di un programma è una rottura. L'analisi statica è un incubo!!

E' questo il senso del "se hai i sorgenti è meglio".

[Phoenix Fire]

Originariamente inviato da pabloski

A parte che bisognerebbe chiarire che cosa significa "vera sicurezza". Comunque sia avere i sorgenti non vuol dire che sia possibile realizzare software bug-free.

Non so se avete idea di quant'è complesso un sistema operativo, con quali complessi pezzi di firmware e hardware interagisce ( che sono buggati a loro volta ) e a tutto questo bisogna aggiungere le rogne colossali dovute all'esecuzione concorrente dei task.

Esistono metodologie ingegneristiche che aiutano, ma sono totalmente insufficiente.

Per questo al primo anno d'informatica/ingegneria il prof ti dice "il software bug free non esiste".

Detto questo, è lapalissiano che i sorgenti consentono di trovare i bug più velocemente. Ma parliamo di sorgenti in C, scritti in un linguaggio che sa essere criptico.

C'era un bug in openssl in debian. Rimase lì per anni. Centinaia di programmatori c'avevano messo gli occhi sopra e non l'avevano visto.

Ma ci sono pure bug che si vedono a colpo d'occhio. E che purtroppo si vedono molto meno se il listato è in Assembly invece che in C.

L'analisi dinamica del flusso d'esecuzione di un programma è una rottura. L'analisi statica è un incubo!!

E' questo il senso del "se hai i sorgenti è meglio".

va anche aggiunto che l'avere i sorgenti pubblici aiuta a trovare i bug anche agli utenti malevoli, quindi è sempre un arma a doppio taglio (con una lama molto più grande dell'altra ovviamente )

[pabloski]

Originariamente inviato da emiliano84

Io sono d'accordo con te, ma a uno come luke che ti scrive quelle cose, come gli rispondi?

Non gli rispondere.

Originariamente inviato da Phoenix Fire

va anche aggiunto che l'avere i sorgenti pubblici aiuta a trovare i bug anche agli utenti malevoli, quindi è sempre un arma a doppio taglio (con una lama molto più grande dell'altra ovviamente )

La questione è che gli utenti malevoli ( che poi sono gli Stati, visto l'andazzo ) hanno strumenti sofisticatissimi, in grado di scovare bug pure a partire dai binari.

Il ricercatore whitehat è invece spesso a corto di mezzi e i sorgenti l'aiutano parecchio.

E si spera che il numero dei whitehat sia superiore a quello dei blackhat.

[zappy]

Originariamente inviato da tallines

Mai usato G Suite, G Mail e tutte quelle tafanate li

[zappy]

Originariamente inviato da pabloski

...Per questo al primo anno d'informatica/ingegneria il prof ti dice "il software bug free non esiste"...

mi sa tanto di scusa.
ormai tutto "si può aggiornare dopo il rilascio" e quindi si mette sul mercato della merda, eventualmente aggiustandola dopo.

che so, l'ABS di un'auto è un sw. Non mi risulta che venga messo in commercio con bachi, se non in casi rarissimi.

Per cui il fatto che un sw senza bachi sia "impossibile" mi sa tanto di luogo comune. Si, se lo fai col culo e lo butti fuori in mezza giornata, avrà dei bachi...

[pabloski]

Originariamente inviato da zappy

mi sa tanto di scusa.
ormai tutto "si può aggiornare dopo il rilascio" e quindi si mette sul mercato della merda, eventualmente aggiustandola dopo.

Beh no. E' una triste constatazione della realtà.

Originariamente inviato da zappy

che so, l'ABS di un'auto è un sw. Non mi risulta che venga messo in commercio con bachi, se non in casi rarissimi.

Semplicemente opera in un ambiente il cui spazio di input non si allontana molto da quello previsto.

Altra situazione è invece quella di device general purpose, tipo i computer desktop/server.

Originariamente inviato da zappy

Per cui il fatto che un sw senza bachi sia "impossibile" mi sa tanto di luogo comune. Si, se lo fai col culo e lo butti fuori in mezza giornata, avrà dei bachi...

Ma puoi mettertici tutta la vita, non esiste che puoi realizzare un software con zero bug.

L'unica possibilità ( e vale per i sistemi come gli ABS, dove puoi imporre che gli input ricadano solo in un determinato range ) è la verifica formale. Ma parliamo di un qualcosa di applicabile con estrema difficoltà e su software relativamente semplici.

Cioè non esiste che si possa verificare formalmente un web server, ad esempio.

[LukeIlBello]

Originariamente inviato da pabloski

A parte che bisognerebbe chiarire che cosa significa "vera sicurezza". Comunque sia avere i sorgenti non vuol dire che sia possibile realizzare software bug-free.

Non so se avete idea di quant'è complesso un sistema operativo, con quali complessi pezzi di firmware e hardware interagisce ( che sono buggati a loro volta ) e a tutto questo bisogna aggiungere le rogne colossali dovute all'esecuzione concorrente dei task.

Esistono metodologie ingegneristiche che aiutano, ma sono totalmente insufficiente.

Per questo al primo anno d'informatica/ingegneria il prof ti dice "il software bug free non esiste".

Detto questo, è lapalissiano che i sorgenti consentono di trovare i bug più velocemente. Ma parliamo di sorgenti in C, scritti in un linguaggio che sa essere criptico.

C'era un bug in openssl in debian. Rimase lì per anni. Centinaia di programmatori c'avevano messo gli occhi sopra e non l'avevano visto.

Ma ci sono pure bug che si vedono a colpo d'occhio. E che purtroppo si vedono molto meno se il listato è in Assembly invece che in C.

L'analisi dinamica del flusso d'esecuzione di un programma è una rottura. L'analisi statica è un incubo!!

E' questo il senso del "se hai i sorgenti è meglio".

[LukeIlBello]

Originariamente inviato da zappy

mi sa tanto di scusa.
ormai tutto "si può aggiornare dopo il rilascio" e quindi si mette sul mercato della merda, eventualmente aggiustandola dopo.

che so, l'ABS di un'auto è un sw. Non mi risulta che venga messo in commercio con bachi, se non in casi rarissimi.

Per cui il fatto che un sw senza bachi sia "impossibile" mi sa tanto di luogo comune. Si, se lo fai col culo e lo butti fuori in mezza giornata, avrà dei bachi...

invece purtroppo è vero non sono scuse
l'unica arma è il debug e beta testing (che Molte Sw house non applicano )

[LukeIlBello]

Originariamente inviato da emiliano84

Io sono d'accordo con te, ma a uno come luke che ti scrive quelle cose, come gli rispondi?

qua scusa ma me deludi..
un concetto trova la sua correttezza nel suo essere non in chi lo espone
avresti dovuto darmi ragione

[zappy]

Originariamente inviato da LukeIlBello

invece purtroppo è vero non sono scuse
l'unica arma è il debug e beta testing (che Molte Sw house non applicano )

appunto. il problema è che non viene testato.

Sogei ne sa qualcosa

[LukeIlBello]

Originariamente inviato da zappy

appunto. il problema è che non viene testato.

Sogei ne sa qualcosa

ah se intendi quello si

[zappy]

Originariamente inviato da pabloski

...Semplicemente opera in un ambiente il cui spazio di input non si allontana molto da quello previsto....

beh, anche un pc ha una interfaccia ben definita, e la "roba" arriva da lì.
una tastiera trasmette caratteri, un mouse coordinate... ecc.
poi chiaro che (forse) è più complesso di un ABS, ma ciò non toglie che sono sw entrambi.

Cioè non esiste che si possa verificare formalmente un web server, ad esempio.

sorry ma non so cosa significhi di preciso.

[zappy]

Originariamente inviato da LukeIlBello

ah se intendi quello si

beh, certo: intendo il rilascio "al pubblico".
È ovvio che di bachi mentre lo scrivi ce ne sono, a meno che uno non sia un genio...
io scrivo cazzatine, ma poi le "torturo" con tutti i generi di input possibili da parte dell'utente, e alla fine di bachi non ce ne sono, o se ci sono semplicemente dice "errore" e si ferma, senza fare casini.

[pabloski]

Originariamente inviato da zappy

beh, anche un pc ha una interfaccia ben definita, e la "roba" arriva da lì.

Si, ma ha tante personalità.

Pensa al bug di OpenSSL in Debian. Lì il problema era che un numero intero a 32 bit veniva trattato dal programmatore come un uint. Il mantainer del pacchetto aveva rimosso un if ed era successo il casino.

Il punto è che l'ABS invece, sa che i numeri che gli arriveranno sono necessariamente di un solo tipo. I programmatori lo sanno. Il linguaggio ( si usano linguaggi un pelino più espressivi del C ) pure.

Originariamente inviato da zappy

una tastiera trasmette caratteri, un mouse coordinate... ecc.

Il problema è l'interpretazione. Un carattere può essere incastonato in un tipo di dato di diversa natura.

Tecnicamente ( se non mi sbaglio ) sono stringhe di 16 bit che compongono gli scancode. Ma lo leggi come int, uint, short, widechar? E in base al modello di programmazione del linguaggio potresti ritrovarti ad avere a che fare con un dominio di valori totalmente diverso.

Per cui se uso un uint sono sicuro che non dovrò mai usare un if per controllare se x < 0 ( perchè non può esserlo by design ).

Ed è qui che la verifica formale entra in gioco. Crei un modello matematico del software, con tanto di tipi di dato e relativi domini. E su quello ragioni, usando operatori analitici.

E la matematica è bella perchè è sintetica, cioè è in grado di dirti ( applicando un operatore ) se un predicato su una variabile è vero e in quali condizioni. Mentre in programmazione devi ragionare iterativamente.

Il problema è che creare un modello matematico di un pc in esecuzione è impossibile.

[zappy]

Originariamente inviato da pabloski

Si, ma ha tante personalità
....
Il problema è che creare un modello matematico di un pc in esecuzione è impossibile.

ammetto che ho capito poc(issim)o del tuo post...

ok, quindi i bug sono "cose" messe in "tipi" non conformi.
non dovrebbe essere difficilissimo automatizzare una procedura che individua tutte le variabili e ci butta dentro la qualunque, per vedere che succede...

e cmq, non è che hai bisogno di un modello dell'intero pc con tutto quanto dalla A alla Z, da 0 a F... devi debuggare il TUO sw, non il mondo.
poi ripeto, non scrivo sw per lavoro, magari dico cazzate.

[Phoenix Fire]

Originariamente inviato da zappy

ammetto che ho capito poc(issim)o del tuo post...

ok, quindi i bug sono "cose" messe in "tipi" non conformi.
non dovrebbe essere difficilissimo automatizzare una procedura che individua tutte le variabili e ci butta dentro la qualunque, per vedere che succede...

e cmq, non è che hai bisogno di un modello dell'intero pc con tutto quanto dalla A alla Z, da 0 a F... devi debuggare il TUO sw, non il mondo.
poi ripeto, non scrivo sw per lavoro, magari dico cazzate.

questa l'hai detta giusta
scherzi a parte, i problemi sono principalmente 2:

• non puoi testare tutte le possibili combinazioni e interazioni di input
• il software può girare in condizioni "Impreviste" o essere collegato con altri hw/sw non previsti