Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Giu Mag Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Un-be-lie-va-ble

Questo buco nel mio nuovo telefonino G1 ha l’impressione di essere un traforo del monte bianco:

anything you type into your keyboard is also being run in a hidden console with root permissions.

Praticamente tutto quello che si scrive sulla tastiera viene eseguito anche in una console non visibile. E se si chiaccia (enter)reboot(enter) il telefono si riavvia. Qualcuno l’ha chiamato Worst. Bug. Ever.

Post da tenere caro ogni volta che viene ‘vantata’ la presunta sicurezza intrinseca dell’open source.

Aggiornamento: ieri è finalmente arrivato l’update di sistema. L’esperienza dell’upgrade, soprattutto se confrontata con prodotti analoghi, è stupenda.

-quack

Technorati Tags: ,

Potrebbero interessarti anche:
Commenti (44): [ Pagina 1 di 2  - più vecchi ]
15. Luigi Bruno
domenica 9 novembre 2008 alle 7:21 PM - unknown unknown unknown
   

Fantastico! Chi è il genio che ha creato tutto ciò?

   
16. NickelGreen
domenica 9 novembre 2008 alle 7:47 PM - unknown unknown unknown
   

Provate a chiedere ad un meccanico se comprerebbe un'auto di cui può leggere il manuale ma non può aprire il cofano e vediamo cosa risponde. Secondo me vi manda a quel paese, o no?

Ahhhh, ma tipo l'iPhone?

   
17. Gabriele
domenica 9 novembre 2008 alle 11:09 PM - unknown unknown unknown
   

Non scrafiamo i figli dei meccanici, please! Mai sentito parlare di auditing indipendente del codice?

Comunque mi pare che i tizi del blog avessero trovato una soluzione leggendo il codice, Mica hanno dovuto ravanare per forum alla ricerca della magica chiave del registro DisableThisOrribleBug da impostare a 1 senza averci capito un cavolo.

L'esempio del meccanico calza e io sono senz'altro il figlio sedicenne, diciamo anche non tanto sveglio. Ma curioso. La security by obscurity tiene alla larga dalla porta il figlio sedicenne e la spalanca a chi vuole veramente fare danno. Se ci sono 5 distribuzioni Linux, ciascuna con il suo team di sicurezza che revisiona il codice, le probabilità di bug sono più basse rispetto a far fare tutto al produttore (e Google non fa eccezione). Si sa per l'oste il vino è sempre buono

   
18. Scrooge McDuck
domenica 9 novembre 2008 alle 11:43 PM - unknown unknown unknown
   

Non scrafiamo i figli dei meccanici, please! Mai sentito parlare di auditing indipendente del codice?

E che risultati apporta? Non basta che qualcuno faccia auditing del codice per assicurarne la bontà, la sicurezza è un processo, non una semplice questione di quanti hanno voglia di dare una guardata al codice.

Comunque mi pare che i tizi del blog avessero trovato una soluzione leggendo il codice, Mica hanno dovuto ravanare per forum alla ricerca della magica chiave del registro DisableThisOrribleBug da impostare a 1 senza averci capito un cavolo.

Buona, sicura? Questo non lo sappiamo, su questioni del genere le modifiche vanno fatte da chi conosce il sistema, non dal primo tizio che passa di lì e scrive del codice che poi non testa. Per l'utente comune quella soluzione non serve a niente, nada, come se non ci fosse.

La security by obscurity tiene alla larga dalla porta il figlio sedicenne e la spalanca a chi vuole veramente fare danno.

Non diciamo fesserie, se un baco è conosciuto chi vuole fare danno lo farà senza problema, semplicemente è possibile (non necessariamente vero ovviamente, in questo caso temo che non ci sarebbero state differenze) che lo sfruttamento sia più difficoltoso senza conoscere il funzionamento interno. E il figlio sedicenne non serve ad un mazza in ogni caso (non per i bachi di sicurezza almeno).

Se ci sono 5 distribuzioni Linux, ciascuna con il suo team di sicurezza che revisiona il codice, le probabilità di bug sono più basse rispetto a far fare tutto al produttore (e Google non fa eccezione).

Magari, la realtà invece ci dice che le mille mila distribuzioni portano, nei casi peggiori, ad avere patch fatte a culo che compromettono la sicurezza di chissà quanti sistemi (debian anyone?), forse con una distribuzione sola, con processi migliori e più standardizzati per l'approvazione delle patch questo problema si sarebbe potuto evitare.

   
19. Paperino
lunedì 10 novembre 2008 alle 1:41 AM - unknown unknown unknown
   

Quindi mi sembra la cosa sia stata sistemata.

yes, ma a me l'aggiornamento non è ancora arrivato.

   
20. Gabriele
lunedì 10 novembre 2008 alle 10:54 AM - unknown unknown unknown
   

@Scrooge McDuck

debian anyone?

Questa insinuazione non è elegante. Gli errori sono talmente rari che fanno subito notizia. Peraltro l'errore (l'orrore, diciamo) è stato corretto in pochissimo tempo. E' bastato ricreare le coppie chiavi nel caso in cui fossero state create male. Per carità errore gravissimo. Ma assai raro.

Dal punto di vista della sicurezza non mi pare si possa fare paragoni. Non ci sono stati Sasser, c'è un team di sicurezza che lavora alla luce del sole, non ci sono problemi importanti di sicurezza non patchati. Fatti conto che più o meno l'errore descritto prima corrisponda a tutti gli avvisi di sicurezza che Microsoft descrive con la frase ("che a me fa accapponare la pelle"): "E' stato scoperto un problema... che potrebbe permettere ad un malintenzionato di prendere pieno possesso del sistema o di eseguire codice a sua scelta.

Guarda questo

www.microsoft.com/.../MS08-054.mspx

Dico ma secondo te è possibile compromettere un server per una vulnerabilità a Windows Media Player??

Hai letto i dettagli?

If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Fa paura o no? Che cavolo ci fai su Windows Server 2003 se non ti logghi come Amministratore? E lo posso togliere WMP? Forse la versione 11 mi posso evitare di installarla ma disinstallarle tutte mica è facile anche da un server. E questo è triste.

Oppure

www.microsoft.com/.../MS08-067.mspx

On Microsoft Windows 2000, Windows XP, and Windows Server 2003 systems, an attacker could exploit this vulnerability without authentication to run arbitrary code

Ora, io sono molto contento che questi bugs assai gravi vengano trovati e corretti, vuol dire che ci guardano e che ora i server sono più sicuri per tutti. Però il tutto è sempre a totale discrezione del padrone di casa che può sempre dire... non ci risulta... i nostri sistemi sono sicurissimi e chi dice il contrario è un diffamatore... e avrebbe subito centomila fan-boys nei forum a dargli ragione.

Il viceversa non è vero. Se inizializzi un buffer di dimensione fissata, non controlli cosa ci metti dentro e 10 programmatori decenti leggono il tuo codice qualcuno te lo contesta di sicuro.

Poi vuoi mettere l'impegno che ci mettono gli esperti di sicurezza nello studiare il codice e dire "ho trovato una vulnerabilità nel kernel di linux" diventi subito ricercato se sei bravo.

Per finire e stemperare un po' i toni, vi lascio una chicca a proposito del bug di openssh che è stato citato prima (e che, proprio perché introdotto dagli sviluppatori debian, ha fatto storia)

blog.rogeriopvl.com/.../dilbert_debian.jpg

   
21. il nonno
lunedì 10 novembre 2008 alle 11:32 AM - unknown unknown unknown
   

@Gabriele

potevi trovare degli esempi migliori, che WMP abbia una vulnerabilita' sullo streaming audio sai che preoppupazione puo' procurarmi se ho un server? Nessuna!

   
22. Gabriele
lunedì 10 novembre 2008 alle 11:39 AM - unknown unknown unknown
   

@il nonno

Perché, WMP lo puoi levare? E IE, lo puoi levare?

Se uno dei componenti di sistema ha un problema così la preoccupazione è alta. Io sui server debian non ho il server X. Niente grafica, minore superficie di attacco. Niente Office, niente Firefox, se vuoi navigare vai su un PC.

In Windows Server 2003 non lo puoi fare. Tutto troppo integrato. E ci è anche costato caro. In Windows Server 2008 le cose migliorano, che voi sappiate?

   
23. Daniele
lunedì 10 novembre 2008 alle 11:49 AM - unknown unknown unknown
   

@Gabriele: "Peraltro l'errore (l'orrore, diciamo) è stato corretto in pochissimo tempo"

 

Già, solo 2 anni

   
24. Enrico C.
lunedì 10 novembre 2008 alle 11:54 AM - unknown unknown unknown
   

Su ragazzi, tutti i sistemi hanno bugs e vulnerabilità, non possiamo farci niente se non rilasciare dei bugfixes, relax. Se poi contassimo le linee di codice di Windows Vista e Windows Server 2008 sarebbe del tutto normale dedurne che abbiamo più vulnerabilità su questi sistemi.

Più linee di codice ---> Più bugs & vulnerabilità. Sono variabili direttamente proporzionali. (a parità di errori umani, ovvero ammettendo che i developers Microsoft sono *tanto abili quanto* il resto dei developers).

A proposito, per stemperare i toni:

www.enricocasini.com/.../scoperto-il-codice-sor...

Tutto vero

   
25. il nonno
lunedì 10 novembre 2008 alle 12:15 PM - unknown unknown unknown
   

@Gabriele,

a parte che anni che lavoro su Windows Server non ho mai aperto WMP, a parte che basta disabilitare le Visualization per essere immuni da quel baco... che me ne frega che ci siano o no i binari di WMP sul server? Sinceramente non mi pongo proprio il problema perche' e' un NON problema.

La tua definizione di superficie d'attacco e' impropria, perche'  WMP non offre alcuna superficie d'attacco se non lo uso, non e' certo la sua presenza in se' che causa problemi.

   
26. Blackstorm
lunedì 10 novembre 2008 alle 2:21 PM - unknown unknown unknown
   

@Gabriele:

Perché, WMP lo puoi levare? E IE, lo puoi levare?

Se non li usi, è difficile che diventino vettori di attacco. E non mi risulta che un admin faccia girare wmp su un server per guardarsi il uso pornazzo. E se lo fa, merita di trovarsi il sistema compromesso. Quanto a IE è un browser e potrebbe anche sevire, magari per gestire da remoto una macchina fuori sede che non ha un accesso in ssh.

Se uno dei componenti di sistema ha un problema così la preoccupazione è alta. Io sui server debian non ho il server X. Niente grafica, minore superficie di attacco. Niente Office, niente Firefox, se vuoi navigare vai su un PC.

Ok, ma il fatto di averli, non implica il doverli usare per forza, no? Voglio dire, se tu su una macchina server ti metti a giochicchiare su inet, o se ti guardi un film o quel che vuoi, allora lo fai a prescindere dall'avere su win, mac o linux. Su questo sarai d'accordo.

In Windows Server 2003 non lo puoi fare. Tutto troppo integrato. E ci è anche costato caro. In Windows Server 2008 le cose migliorano, che voi sappiate?

Mah, non saprei dirti, finora le recensioni che ho letto sono state tutte molto positive...

   
27. Blackstorm
lunedì 10 novembre 2008 alle 2:22 PM - unknown unknown unknown
   

@EnricoC:

carino il link, ma è vecchio come XP, dato che pochi mesi dopo l'uscita di XP girava praticamente lo stesso identico joke, con un paio di differenze...

   
28. FDG
lunedì 10 novembre 2008 alle 2:47 PM - unknown unknown unknown
   

Google ha avuto troppa fretta. E si vede, se i risultati sono questi. Già da quel che hai scritto tu, ma non solo tu, si capisce che il software ha ancora qualche problema di troppo.

@Paperino

Obiezione. Per scoprire un baco il sorgente quasi sempre non aiuta

Io non voglio esser polemico. Però tra un software di cui ho controllo ed uno di cui non posso controllare nulla, preferisco il primo. Alla fine è questa la differenza: sai che c'è un problema, hai strumenti per tentare di aggirarlo, magari anche per risolverlo. Anche per capire se è così problematico da spingermi a non usarlo più. Questa convinzione nasce dall'esperienza maturata sulle librerie java. Quando una di questa ha un problema, una possibilità è andare a vedere dentro la libreria per capire cosa fa (e si capisce, basta studiarsi il codice, male che vada è conoscenza condivisa che trovi in rete, conoscenza a cui puoi accedere apertamente). Di per se questo non vuol dire che la libreria sia automaticamente scritta bene. Però se ad un certo punto ho scritto parecchio codice che la usa e questa mi da un problema, ho almeno una possibilità in più. Nel momento in cui questa possibilità non c'è... mi attacco al tram (la conoscenza chiusa semplicemente non è accessibile). Non è la situazione che preferisco.

@Scrooge McDuck

L'esempio del meccanico poi è forviante, il meccanico è specializzato e sa come riparare un'auto (figura paragonabile quindi a chi lavora al progetto), chi si legge il codice e cerca di capirci qualcosa/metterci eventualmente una pezza è paragonabile al figlio sedicenne del meccanico che ha visto lavorare il padre ma non ha esperienze di riparazione

Tu parti dal presupposto che chi legga il codice sia automaticamente un incapace. Però questo è una invariante del problema. Ci sono quelli che non sono capaci. Siccome io il codice lo so leggere, preferisco averlo a disposizione. Male che vada, se non riesco a leggerlo, mi trovo nella stessa situazione in cui non ho il codice. Il fatto che tu lo ritenga comunque inutile è una tua considerazione. Vuol dire che tu ti risolvi (forse) i problemi senza l'aiuto del codice. Ma oggettivamente questo è un limite. Questo non c'entra nulla col rilascio delle patch. Quello è un problema di gestione del progetto. Se i reviewer non sono attenti, il risultato è che modifiche fatte alla leggera possono produrre danni. Ma anche questa è una cosa che non dipende dalle modalità di distribuzione del codice. Non c'è legame. Può capitare in un progetto open come in uno closed.

E che risultati apporta? Non basta che qualcuno faccia auditing del codice per assicurarne la bontà, la sicurezza è un processo, non una semplice questione di quanti hanno voglia di dare una guardata al codice.

Concordo sul fatto che sia un processo. Però personalmente preferisco avere il codice. Ho spiegato già perché.

Spero di aver chiarito il mio pensiero.

   
29. Scrooge McDuck
lunedì 10 novembre 2008 alle 2:53 PM - unknown unknown unknown
   

Dal punto di vista della sicurezza non mi pare si possa fare paragoni. Non ci sono stati Sasser, c'è un team di sicurezza che lavora alla luce del sole, non ci sono problemi importanti di sicurezza non patchati.

http://en.wikipedia.org/wiki/Sasser_(computer_worm)

Leggiamo la pagina

The specific hole Sasser exploits is documented by Microsoft in its MS04-011 bulletin, for which a patch had been released seventeen days earlier.

Chissà come moltissimi dei worm che si diffondono su windows e per cui il SO viene aspramente criticato sfruttano vulnerabilità già patchate da tempo. E' troppo facile parlare dell'insicurezza di windows quando gli utenti che lo utilizzano sono generalmente così beoti da non aggiornare il sistema (magari perché non lo hanno originale, cosa che non impedisce loro di lamentarsi quando qualcosa non va). Purtroppo non ci si possa fare niente (è il problema intrinseco di avere una tale base di utenza) ma sarebbe corretto non dare la colpa solo a Windows quando vengono sfruttate vulnerabilità patchate in precedenza.

Per la prima vulnerabilità ti hanno già risposto (non basta che WMP sia installato, non è un demone/servizio), per la seconda vorrei comunque farti notare che di default ormai il firewall è sempre attivo, e già questo rende impossibile lo sfruttamento di un bug simile. Poi sulla pericolosità non si discute ma parliamo comunque di un bug che out of the box non è sfruttabile (sicuramente da XP SP2 in poi, da prima non so), può sicuramente far danni ma si è visto di peggio. Inoltre su Vista/Server 2008 è ancora meno sfruttbile, segno comunque che ci sono dei passi avanti dal punto di vista della sicurezza.

Il viceversa non è vero. Se inizializzi un buffer di dimensione fissata, non controlli cosa ci metti dentro e 10 programmatori decenti leggono il tuo codice qualcuno te lo contesta di sicuro.

Bisogna vedere se tra i programmatori Microsoft qualcuno che fa orrori del genere c'è. Da quello che diceva Paperino tempo fa era praticamente impossibile che del codice venisse accettato (e francamente non credo che prendano gente così sprovveduta da scrivere codice così vulnerabile a dei buffer overflow).

   
30. Paperino
lunedì 10 novembre 2008 alle 6:35 PM - unknown unknown unknown
   

@FDG:

Spero di aver chiarito il mio pensiero.

Chiarissimo, ma lasciami precisare su cosa non sono assolutamente d'accordo, e cioé questa frase:

Però tra un software di cui ho controllo ed uno di cui non posso controllare nulla, preferisco il primo.

Tu pensi che basti avere il codice sorgente a disposizione per avere il "controllo"? Io sono convinto di no. Per avere il controllo devi avere l'ownership di quel pezzo di codice. Devi essere in grado di rispondere in maniera abbastanza attendibile alle domande del tipo "cosa succede se cambi questo così...". Sapendo che quel codice viene pure usato in maniera poco ortodossa. Insomma non devi necessariamente averlo scritto ma per definirti owner dev'essere come se lo avessi scritto tu. Avere il codice è condizione necessaria ma non sufficiente, questo è il succo del problema. Infatti, ad eccezione del RNG di Debian (ci torno), tutte le altre vulnerabilità - incluse le più "visibili" backdoor - sono sempre state scoperte con l'approccio di black box. Lo stesso baco di Android è stato scoperto accidentalmente da una persona che ha scritto Reboot e ha riavviato il suo cellulare... Per questo contestavo l'affermazione di Gabriele che il codice torna utile per scoprire i bachi.

Nel caso del RNG di Debian il codice è stato indispensabile: sfido chiunque a capire da una serie di numeri casuali che c'è poca entropia. È stato scoperto accidentalmente da uno sviluppatore italiano che su quel codice ci stava "indagando" per altri motivi. Paradossalmente la scoperta della vulnerabilità - come da sempre avviene con tutte le vulnerabilità di questo pianeta - ha portato qualche mente sopraffina a individuare un exploit (mi sembra lo stesso scopritore) usabile per decriptare le connessioni SSL. Chiediti cosa sarebbe successo se una vulnerabilità simile non fosse venuta alla luce: niente di niente, tutti useremmo connessioni SSL facilmente decriptabili ed il problema non si sarebbe mai posto. A meno che... a meno che qualche altra mente sopraffina (magari qualcuno che lavora all'NSA?) avesse scoperto lo stesso baco e avesse tenuto l'informazione preziosa per sé. Cosa possibile con l'open source, ma un pelino più complesso se il codice fosse preziosamente custodito (non è il caso di Windows, visto che le agenzie governative ne hanno facoltà di accesso). Ma questo è il minore dei problemi. Il più grosso è che a quanto pare, anche per una distro come Debian, il processo di sviluppo e revisione ha falle piuttosto visibili se permette a tabaccai incompetenti di modificare e ripubblicare parti delicate del sistema nonostante avesse pure avuto pareri molto contrari. Questo incide sulla qualità e quindi sulla sicurezza in misura molto maggiore dell'effetto (per me risibile) della "security by many eyeballs".

Insomma se sto aspettando la patch ufficiale per Android non è per snobismo nei confronti di chi il codice è capacissimo di leggerlo, ma per rispetto non gratuito di chi ne è invece owner.

@Gabriele:

Su Win2k3 IE installato di default è hardened. Anche per scaricare un file da internet devi sottoporti a terzo grado. Non riesco a vedere i vantaggi di avere IE in tal caso come componente opzionale.

Su Debian vorrei farti una tiratina di orecchie: uscirsene fuori con "il baco è stato sistemato in pochissimo tempo" vuol dire porre l'accento sull'aspetto meno rilevante della questione. Ci mancherebbe altro che per fare una revert del codice ad una condizione precedente e testata per decenni avesse richiesto più di qualche minuto! Un aspetto più rilevante è che l'update richiede la rigenerazione delle chiavi, cosa che a quanto pare non avviene in maniera automatica. L'aspetto secondo me più rilevante è che il baco ha causato un danno irreparabile: puoi rigenerare tutte le chiavi che vuoi, ma niente può sistemare il senso di sfiducia che si è instaurato nei confronti dell'SSL. Chi mi dice che dall'altra parte della connessione ci sia un admin diligente che ha rigenerato le chiavi su Debian?

Per quanto riguarda OOXML, ti dico schiettamente come la penso. La questione è diventata macchiavellica. ODF, dal punto di vista tecnico, ha lacune molto vistose: come si può promuovere un formato per la sua interoperabilità quando la definizione di "FORMULE" per il foglio di calcolo non esiste ed è stata lasciata alla libera implementazione? Al contrario OOXML è così dettagliato (anche se a tratti mancavano "pezzi di specifiche" poi successivamente integrati) da richiedere una poderosa documentazione. Sicuramente OOXML non è la migliore soluzione al problema dell'interoperabilità ma se permetti ODF è persino peggio. Ed infatti tu stesso per fare il raffronto con delle specifiche ottime usi GZip anziché ODF. Machiavellicamente dico che in questo caso il fine (interoperabilità, con MS che ha una voce proporzionale alla sua importanza e non market share) giustifica i mezzi di un formato poco più che decente: infatti il passo successivo è stato quello di creare una commissione per l'unificazione dei due formati. Amen.

Due parole su PHP vs. .Net: nessuna trappola. Da quello che scrivevi mi hai dato l'impressione che ci fossero cose che con lo stack LAMP si potessero fare, ma che con lo stack MS fossero impossibili. A me, a parte la possibilità di customizzare modificando il codice direttamente lo stack, è sembrato il contrario. Ovvero che .Net sia molto più "potente" di PHP a livello espressivo e di funzionalità come questa vignetta chiaramente dimostra. L'impressione è che molto spesso le critiche siano basate su pregiudizi fissati sulla Microsoft di 10 anni fa.

@tutti:

due parole sulla security by obscurity. Tutti ne parlano male, in realtà come faceva notare qualcuno se si aggiunge l'obscurity a tutto il resto non si fa che rendere un sistema più sicuro. L'esempio più lampante è questo: tutti sanno che i Windows TS ascoltano sulla porta 3389 di default. Se io la impostassi su 4000 e se un giorno venisse scoperto un baco nel protocollo, sarei meno esposto di chi usa la porta 3389 di default visto e considerato che la strategia comune di chi cerca di sfruttare tali vulnerabilità per scopi loschi è di cercare quante più macchine vulnerabili possibili nel tempo più breve. Questo però non deve essere una scusa per fare la cosa corretta: installare le patch il più velocemente possibile.

   
31. Gabriele
lunedì 10 novembre 2008 alle 7:57 PM - unknown unknown unknown
   

@Paperino

Chi mi dice che dall'altra parte della connessione ci sia un admin diligente che ha rigenerato le chiavi su Debian?

Il fatto che ti si connette! Infatti se sono chiavi di tipo compromesso non le accetta più né il client né il server. In più puoi controllare di default se sono compromesse, l'aggiornamento del pacchetto le verifica ed in caso le ricrea... non mi pare sia andata poi malissimo (vista la cazzata di partenza).

SSL è accettabilissimo come standard e puoi averne estrema fiducia. Se implementato bene (cosa che vale per ogni cosa a questo mondo) ha ricevuto vasta approvazione dalla comunità scientifica, si basa su algoritmi peer-reviewed a livello internazionale e se ne sanno i pregi (molti) ed i difetti (pochi) da anni. Scusa, che algoritmo di criptazione usa Windows Update? E' noto? Chi lo dice che è buono? Chi lo dice che la CIA non registri tutto? E' peer-reviewed? E io lo posso ricompilare per essere sicuro che giri solo il codice che voglio io?

A volte il codice aperto serve.

   
32. Paperino
lunedì 10 novembre 2008 alle 8:19 PM - unknown unknown unknown
   

@Gabriele:

Infatti se sono chiavi di tipo compromesso non le accetta più né il client né il server.

Non mi risulta che tutte le chiavi "compromettibili" (?) siano state messe nella revocation list. Ho addirittura il dubbio che si possa fare, dovrebbe essere un quantitativo non indifferente. Hai qualche link a proposito?

Scusa, che algoritmo di criptazione usa Windows Update? E' noto? Chi lo dice che è buono? Chi lo dice che la CIA non registri tutto? E' peer-reviewed?

Certo. Non so i dettagli specifici di WU ma ad esempio (visto che mi sono interessato in prima persona) gli algoritmi di Bitlocker sono documentati, peer-reviewed, ecc. Immagino che il protocollo di WU sia pure documentato, se vuoi posso ravanare.

 E io lo posso ricompilare per essere sicuro che giri solo il codice che voglio io?

No. Ci sono tante cose che è giusto che come utente tu non possa fare. Ad esempio installare driver non firmati su Vista x64. Non tutte le limitazioni vengono per nuocere.

   
33. Gabriele
martedì 11 novembre 2008 alle 12:07 AM - unknown unknown unknown
   

@Paperino

è giusto che come utente tu non possa fare

Urca. Io sono paranoico ma lo stato-baby sitter non mi convince. Sono adulto e maggiorenne e rispondo delle mie azioni. Dovrei poter far tutto quello che non è reato e tendenzialmente anche diversi reati, che poi pagherò nelle opportune sedi.

In pratica stai dicendo che mi devo fidare dell'oste che dice che il vino è buono. Guarda che poi io in realtà ci credo. E' di sicuro strabuono, ci mancherebbe. Però se hai qualche link di dettagli (niente di illegale, per carità... non vorrei curiosare troppo... poi mi arrivano gli omini con gli occhiali neri a casa...)

Per quanto riguarda le chiavi compromettibili ti segnalo questo

packages.debian.org/search

pacchetto openssh-blacklisted. Cosa contenga si capisce.

Nel pacchetto ssh-client c'è una utility, /usr/bin/ssh-vulnkey

DESCRIPTION
     ssh-vulnkey checks a key against a blacklist of compromised keys.

     A substantial number of keys are known to have been generated using a broken version of OpenSSL distributed by Debian which failed to seed its random number generator correctly.  Keys generated using these OpenSSL versions should be assumed to be compromised.  This tool may be useful in checking for such keys.

     Keys that are compromised cannot be repaired; replacements must be generated using ssh-keygen(1).  Make sure to update authorized_keys files on all systems where compromised keys were permitted to authenticate.

Diciamo che il controllo non è difficile perché sbagliando a inizializzare il seed correttamente si restringeva e di parecchio il numero di chiavi generabili, che quindi con qualche ora di lavoro potevano essere elencate tutte (in realtà tutte quelle più corte, ma usarne di lunghe non è obbligatorio). Bella cavolata, anche se (come direbbero gli strateghi della Microsoft quando pubblicano i bollettini) di default non puoi fare login come root con ssh. Lo devi proprio voler fare. Se ti loggi come utente non privilegiato i danni che puoi fare sono molto minori.

Il bello è che i gli sviluppatori pare abbiano fatto la cavolata cercando di rimuovere qualche warning in compilazione... tipo variabile usata prima di essere inizializzata... ma chissà perché non era inizializzata esplicitamente :). Nessuno è perfetto, gira gira qualche specialista di crittografia se n'è accorto...

   
34. Gabriele
martedì 11 novembre 2008 alle 12:20 AM - unknown unknown unknown
   

Giusto per completezza ecco cosa appariva quando veniva effettuato l'aggiornamento che correggeva il problema. Mi pare che sia abbastanza esplicativo

www.ivan.agliardi.net/.../...n_openssh_warning.jpg

   
35. Paperino
martedì 11 novembre 2008 alle 12:27 AM - unknown unknown unknown
   

@Gabriele:

parlavo di un sistema configurato di default. Poi se ci si vuol far del male nell'installare driver non firmati puoi avviare il sistema in "modalità driver non firmati". Certe applicazioni che dipendono dall'integrità dei driver smettono di funzionare, ma se ci si vuol far del male è il minimo dei problemi, no?

Quanto alle chiavi di debian, il mio problema è piccolo piccolo: io quando mi connetto alla banca via SSL, come faccio a sapere se la banca sta usando le chiavi patchate se sul client uso windows? Non vedo come il pacchetto openssh-blacklisted possa assolutamente aiutarmi. Questo intendevo per affidarmi "alla diligenza" dell'admin.

   
36. Paperino
martedì 11 novembre 2008 alle 12:51 AM - unknown unknown unknown
   

Per quanto riguarda il protocollo di Windows Update comincerei da qui.

P.S. c'è abbastanza documentazione per implementarsi il protocollo in proprio. Sempre se il livello di paranoia è abbastanza elevato.

   
37. Gabriele
martedì 11 novembre 2008 alle 10:18 AM - unknown unknown unknown
   

@Paperino

io quando mi connetto alla banca via SSL, come faccio a sapere se la banca sta usando le chiavi patchate se sul client uso windows?

Intanto il problema si verifica solo con le chiavi generate con una certa versione di openSSL di debian e debian-related. L'implementazione standard di openSSL non è affetta. Solo per questa volta "per fortuna non tutti usano debian"

Nel caso di certificati SSL dovrebbe essere anche coinvolta VeriSign o un'altra certificate authority, che si dovrebbe essere subito attivata per disabilitare le chiavi sospette e riattivata per l'autenticazione delle nuove.

Inoltre ad esempio in Debian anche lato client non ci riesce a connettere in SSH se il server si autentica con una chiave insicura. Quindi anche se il client è patchato ma il server no l'autenticazione fallisce. Quasi sicuramente in SSL è lo stesso. Da verificare che il client openSSL che usi sia aggiornato.

Ricapitolando, secondo me il rischio esiste solo se il server non è patchato, il client non è patchato e la certificate authority ha dormito.

Esistono anche pacchetti analoghi di chiavi openSSL blacklisted, di lunghezza standard e non-standard

packages.ubuntu.com/search

Per chi ne vuole sapere di più

www.metasploit.com/users/hdm/tools/debian-openssl/

P.S. grazie per le info su WinUpdate. Quando posso me le guardo

   
38. Paperino
martedì 11 novembre 2008 alle 7:05 PM - unknown unknown unknown
   

Mi piacerebbe avere un server debian bacato a disposizione e connettermi via SSL per vedere cosa succede. Ce n'è qualcuno che tu sappia là fuori?

   
39. Gimmi
mercoledì 12 novembre 2008 alle 12:55 PM - unknown unknown unknown
   

Smettiamola con questi pipponi opensource vs closedsource. Il bug in Android è stato introdotto quando ancora il sw era closedsource.

Non credo ci sia nient'altro da dire

   
40. Gimmi
mercoledì 12 novembre 2008 alle 1:00 PM - unknown unknown unknown
   

@Paperino: se hai interesse a diffondere informazioni VERE rettifica il tuo post

   
41. Scrooge McDuck
mercoledì 12 novembre 2008 alle 3:47 PM - unknown unknown unknown
   

Cosa c'entra quando è stato inserito il bug?

E se il kernel di linux avesse un baco inserito quando Linus Torvalds ancora non lo aveva reso pubblico (ok, dubito fortemente che sia possibile ma consideratelo un what if) si dovrebbe dire che non è un problema di un software opensource?

Android è opensource e contiene un bug gravissimo, il resto sono arrampicate sui vetri di chi non vuole accettare la cosa.

   
42. Paperino
mercoledì 12 novembre 2008 alle 5:20 PM - unknown unknown unknown
   

@Gimmi:

@Paperino: se hai interesse a diffondere informazioni VERE rettifica il tuo post

Stai scherzando, VERO?

Comunque il traforo del monte Bianco non è l'unica vulnerabilità scoperta di Android. Ce n'è un'altra individuata da Miller, lo stesso tipo che si è portato a casa un MacBook Air durante lo scorso CanSecWest, e questa volta il fatto che Android sia open source non è solo irrilevante, ma ha addirittura un effetto deleterio. A quanto pare non si sono accorti di aver copiato codice contenente un baco già noto:

"What makes this threat unique is that it was 'sought out' based off previous knowledge, since it was a new product using an existing source tree[...]."

   
43. Gabriele
mercoledì 12 novembre 2008 alle 9:54 PM - unknown unknown unknown
   

@Paperino

Mi piacerebbe avere un server debian bacato a disposizione e connettermi via SSL per vedere cosa succede. Ce n'è qualcuno che tu sappia là fuori?

Che sappia io no. Però puoi controllare se quello della tua banca è blacklisted con il seguente (e secondo me assai figo) comando da shell

echo | openssl s_client -connect www.ibm.com:https | openssl-vulnkey -

mettendo al posto di www.ibm.com il dominio della tua banca (peraltro anche il certificato della IBM non è blacklisted ).

I pacchetti da installare (sotto ubuntu recente) sono solo openssl e openssl-blacklist:

sudo aptitude install openssl openssl-blacklist

   
44. Gimmi
sabato 15 novembre 2008 alle 9:19 AM - unknown unknown unknown
   

@Scrooge McDuck:

c'entra eccome. Quel bug è stato introdotto in un progetto closed source. la frase di paperino "Post da tenere caro ogni volta che viene ‘vantata’ la presunta sicurezza intrinseca dell’open source." è fuorviante.

 


   
[ Pagina 1 di 2  - più vecchi ]
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)