Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/le-password-g-suite-salvate-in-chiaro-da-14-anni-google-risolve-il-problema-e-si-scusa_82474.html

Un bug presente dal 2005 ha permesso di salvare le password in testo semplice. Nessun accesso non autorizzato, ma una brutta figura per una società che si vanta di utilizzare pratiche di sicurezza di riferimento

Click sul link per visualizzare la notizia.

E poi dicono dei cinesi....mah!

si ok, ma per le password conservate in chiaro nei cookies? :stordita:

ottimo direi!

Meglio affidarsi a Microsoft

https://nakedsecurity.sophos.com/2019/04/17/microsoft-confirms-outlook-com-and-hotmail-accounts-were-breached/

Meglio affidarsi a Microsoft

https://nakedsecurity.sophos.com/2019/04/17/microsoft-confirms-outlook-com-and-hotmail-accounts-were-breached/

il gatto e la volpe della ciber security moderna :asd:

certo che se G ed M non riescono ad assolvere questi compiti bene...
siamo a posto. :(

certo che se G ed M non riescono ad assolvere questi compiti bene...
siamo a posto. :(

che M non vi riesca non c'è da stupirsi, almeno per chi ha qualche annetto sul capo..
pure G cmq non è che stia sto fiore all'occhiello..
purtroppo se si vuole la vera sicurezza bisogna pubblicare i sorgenti :read:

ooops

https://www.computerworld.com/article/2574593/security-flaw-in-linux-kernel-gets-vendor-patches.html

https://www.stimulustech.com/2019/03/09/new-linux-security-flaw-could-give-hackers-full-system-access/

https://www.zdnet.com/article/new-security-flaw-impacts-most-linux-and-bsd-distros/

https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years

chi ha parlato di ASSENZA di exploit?
qui si parla di tempistiche di patching e soprattutto di RILEVAMENTO :asd:
un bug che dura 15 anni? accettabile magari su un compito in classe di un liceo tecnico :doh:
una cosa del genere è impossibile che si verifichi quando miliardi di persone hanno accesso ai sorgenti :read:

chi ha parlato di ASSENZA di exploit?
qui si parla di tempistiche di patching e soprattutto di RILEVAMENTO :asd:


:mc:

Signore e signori questa é da incorniciare, quindi stai dicendo che 9 anni sono accettabili... Eh si perché l'ultimo link parla di 9 anni... Inoltre se vuoi te ne trovo un altro che se non ricordo male è rimasto per almeno 15...

accettabile al liceo, ma impossibile che si verifichi quando migliaia di oersone hanno accesso ai sorgenti (cit)
Hai scoperto l'acqua calda, devi appigliarsi a tutto pur di gettar fango. :rolleyes:


quando miliardi di persone hanno accesso ai sorgenti:asd:

Signore e signori questa é da incorniciare, quindi stai dicendo che 9 anni sono accettabili... Eh si perché l'ultimo link parla di 9 anni... Inoltre se vuoi te ne trovo un altro che se non ricordo male è rimasto per almeno 15...

"accettabile al liceo, ma impossibile che si verifichi quando miliardi di persone hanno accesso ai sorgenti" (cit)

edit:
inoltre il primo articolo del 2004, parla di falla presente fin dal kernel 2.2 che come saprai bene risale al 1999

ma vedi bug del genere sono sotto i riflettori, una volta che vengono alla luce chiunque può patchare i sorgenti e la situazione è risolta.. :cool:
infatti non ricordo un bug del tipo wannacry o sasser su OS posix..
se parliamo di sicurezza, nulla è piu sicuro di un prodotto che espone al mondo i propri sorgenti, a prescindere poi dai bugs che, per natura del SW, ci saranno sempre.. :O
il problema è l'approccio alla risoluzione dei bug che determina chi ci "capisce" in termini di sicurezza :read:

Hai scoperto l'acqua calda, devi appigliarsi a tutto pur di gettar fango. :rolleyes:


:asd:

che ce trovi da ridere :ciapet:

che ce trovi da ridere :ciapet:
Il fatto che non ci arrivi da solo non è una novità :asd:

chi ha parlato di ASSENZA di exploit?
qui si parla di tempistiche di patching e soprattutto di RILEVAMENTO :asd:
un bug che dura 15 anni? accettabile magari su un compito in classe di un liceo tecnico :doh:
una cosa del genere è impossibile che si verifichi quando miliardi di persone hanno accesso ai sorgenti :read:

https://en.wikipedia.org/wiki/Shellshock_(software_bug)

Shellshock, also known as Bashdoor, is a family of security bugs in the Unix Bash shell, the first of which was disclosed on 24 September 2014.

Analysis of the source code history of Bash shows the bugs had existed since Bash version 1.03 released in September 1989.

qui si parla di tempistiche di patching e soprattutto di RILEVAMENTO
un bug che dura 15 anni? accettabile magari su un compito in classe di un liceo tecnico
una cosa del genere è impossibile che si verifichi quando miliardi di persone hanno accesso ai sorgenti

che me fai da apostolo? :asd:

https://en.wikipedia.org/wiki/Shellshock_(software_bug)

quando da un discorso tecnologico si passa ad uno risalente agli anni 80 beh..
hai vinto tutto :sofico:

Il fatto che non ci arrivi da solo non è una novità :asd:

anche quello per cui modifichi 5 volte lo stesso messaggio, o dai risposte elusive (del tipo: "dico dico ma alla fine non ho detto nulla") non è una novità :sofico:
ma lo stesso mi incuriosisce ogni volta :asd:

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

Incompetenti :O :O :asd: :asd: :rotfl: :rotfl:

ooops

https://www.computerworld.com/article/2574593/security-flaw-in-linux-kernel-gets-vendor-patches.html

https://www.stimulustech.com/2019/03/09/new-linux-security-flaw-could-give-hackers-full-system-access/

https://www.zdnet.com/article/new-security-flaw-impacts-most-linux-and-bsd-distros/

https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years

proprio non riesci a non tirare in mezzo MS Linux pur di difendere google MS

ho preso in prestito la tua frase

che poi sei andato a trovare una news relativa ad un bug del 2004!!! 15 anni fa!

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

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 :D)

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

Non gli rispondere.

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 :D)

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.

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

:mano:

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

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


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.


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.

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".
:mano: :read:

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 :O
l'unica arma è il debug e beta testing (che Molte Sw house non applicano :asd: )

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

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

invece purtroppo è vero non sono scuse :O
l'unica arma è il debug e beta testing (che Molte Sw house non applicano :asd: )
appunto. il problema è che non viene testato.

Sogei ne sa qualcosa :p

appunto. il problema è che non viene testato.

Sogei ne sa qualcosa :p

ah se intendi quello si :asd:

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

ah se intendi quello si :asd:
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.

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.



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.

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

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

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

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

questa l'hai detta giusta :D
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