Newsgroup: it.comp.os.linux.sys
Titolo: [OT] Gravissimo bug di sicurezza in Linux Ubuntu 5.10: la password di superutente è leggibile da tutti gli utenti nel file di log dell'installazione

http://www.ubuntu.com/usn/usn-262-1
E' stato scoperto un gravissimo bug di sicurezza in Linux Ubuntu 5.10:
la password di superutente (amministratore) è leggibile da TUTTI gli
utenti, perchè risulta essere scritta in chiaro nel file di log
dell'installazione. Un qualunque utente quindi può impossessarsi di
quella password e ottenere tutti i privilegi di sistema, con tutte le
conseguenze che ne derivano.
E meno male che linux doveva essere sicuro... :-)
Saluti da P4

 conseguenze che ne derivano.
ok. E' chiaramente un bug.... ma  chissa' perche' ci scommetto la testa
che quel file di log, guarda caso, e' presente nella home directory di
root ;)
Pertanto non e' vero cio che dici: Un qualunque utente NON può
impossessarsi di
quella password, poiche' NON ha accesso alla home di root.
-- 
Massimiliano

 quella password, poiche' NON ha accesso alla home di root.
e sbagli! Quel file di log è accessibile in lettura a tutti gli
utenti, infatti è stato corretto il bug cambiando i diritti di accesso
a quel file di log.
Saluti da P4

P4 ha scritto:

Ma quello che non capisci (o che non vuoi capire) è che ubuntu <>linux
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Un'assicurazione sulla vita e' qualcosa che rende un pover'uomo povero
per tutta la vita, cosi' puo' morire ricco.
		-- Leopold Fechtner

Il problema non è il bug, qualunque software non è esente da bug.
La sicurezza proviene dalla velocità con la quale il bug viene chiuso,
e se il bug viene reso noto..
in questo caso 12 h non mi sembrano molte.. a differenza dei "mesi" di
chi sappiamo..

P4 ha scritto:

Sei coglione perchè qui si parla di XP (te l'hanno già detto ma non fa 
male ripeterlo)
Il problema riguarda SOLO Ubuntu Breezy 5.10
Il problema è GIA STATO RISOLTO
Quella in chiaro non è la password di root (amministratore, che è 
DISABILITATO DI DEFAULT) bensì quella dell'utente creato in fase di 
installazione
Il problema è di fatto limitato alla macchina locale, e legato 
all'esistenza di utenti con privilegi limitati (gli utenti senza 
limitazioni ai privilegi hanno accesso a sudo, quindi non serve a nulla 
andare a scartabellare in /var)
Luca

 Ma quello che non capisci (o che non vuoi capire) è che ubuntu <>linux
Come ho già detto fino alla nausea in altri interventi, so
perfettamente che con il termine linux si intende il kernel, ma so
anche che:
1) con il kernel linux non ci fai nulla dato che non rappresenta un
sistema operativo, così come non ci fai nulla con il solo kernel di
Windows.
2) che il termine generico linux è spesso usato in senso lato per
indicare una distribuzione (sistema operativo) basata sul kernel linux;
sia per comodità di linguaggio, sia per il motivo espresso al punto 1)
e sia perchè ci sono milioni di distribuzioni e citarle tutte sarebbe
impossibile.
Saluti da P4

 conseguenze che ne derivano.
Quindi è locale. Come fa ad essere gravissimo?
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 andare a scartabellare in /var)
lo hai letto il bollettino o spari vaccate senza conoscere le cose?
any local user could see the password of the first user account, which
has full sudo privileges by default.
TUTTI GLI UTENTI vedono la password del primo utente che ha tutti i
FULL sudo privilegi di default!!!!
Vi devo insegnare io, uno che usa Windows, come funziona linux????
Saluti da P4

 Vi devo insegnare io, uno che usa Windows, come funziona linux????
tu devi solo farci ridere, come sopra, e ci riesci benissimo
cio` non toglie che sia una vaccata lasciare nei log la pass
dell'utente base e che la gravita` sia pressoche' zero nella
realta`

 Quindi è locale. Come fa ad essere gravissimo?
Non centra niente se è locale o meno. Tutti gli utenti che usano quel
computer possono accedere alla password di superutente e fare i loro
porci comodi. Se per te questo non è grave.
Saluti da P4

 Saluti da P4
se non vi fosse chiaro non ho specificato che fosse locale, perchè era
ovvio. Anche perchè un utente non locale si deve autenticare prima di
poter accedere alle risorse. Ma cazzo vi devo insegnare tutto io?
Saluti da P4

 e che la gravita` sia pressoche' zero nella realta`
hai idea delle vacchate che stai dicendo con quella frase? Hai idea di
quante realtà esistono in cui uno stesso computer che monta linux è
usato da tante persone diverse (scuole, università, uffici)?
Saluti da P4

 poter accedere alle risorse
e comunque un utente non locale, dopo che si è loggato, è a tutti gli
effetti un utente locale ed è in grado di leggere il file di log.
Saluti da P4

 Come fa ad essere gravissimo?
https://launchpad.net/distros/ubuntu/+source/shadow/+bug/34606
Severity = Critical 


Non conosco Ubuntu ma in linea di principio non ti credo.
1) perche' tu sei P4 :)
2) perche in tutte le distro che conosco i log di installazione vengono
salvati nella home di root, la quale e' accessibile _solo_ dall'utente
root.
-- 
Massimiliano

 P4 wrote:
Si ma mi dici perchè usi firefox e non Iexploder?
Max

 installazione
http://www.ubuntuforums.org/showthread.php?t=143334
 _ in the normal installation mode, the user created can get the root 
privileges with sudo
_ in the expert mode, there is a root account created
In both case, it's possible to get an administrator username/password. 

 Max
Lo avevo detto qualche tempo fa in un post riguardante IE7.
Uso Firefox perchè è migliore come funzionalità rispetto a IE6 SP2,
ma FF NON è più sicuro di IE6 SP2 (le falle dei buffer overflow,
esecuzione di codice arbitrario da remoto, ecc. ci sono state anche in
FF ogni mese). E ho anche detto che quando uscirà la versione finale
di IE7 passerò a IE7. Ecco svelato in maniera chiara il "mistero".
Saluti da P4

Non conosco Ubuntu ma in linea di principio non ti credo.
Perchè tu sei un imbecille!
Lo hai letto il bollettino di sicurezza?
http://www.ubuntu.com/usn/usn-262-1
Karl Øie discovered that the Ubuntu 5.10 installer failed to clean
passwords in the installer log files. Since these files were
world-readable, any local user could see the password of the first
user account, which has full sudo privileges by default.
The updated packages remove the passwords and additionally make the
log files readable only by root.

 log files readable only by root.
quindi è chiaro che se nella patch hanno rimosso la password dal log e hanno 
reso il log leggibile solo dal root, significa che prima era leggibile da 
tutti. 

 Severity = Critical 
Idiota. Quella è la severity del BUG che non ha alcuna attinenza con la
severity della vulnerabilità. Un bug è critico quando deve essere
risolto in fretta, non quando rappresenta un pericolo di sicurezza. Sono
bug critici anche quelli che non hanno attinenza con la sicurezza del
sistema.
Ma che te lo dico a fare??


 usato da tante persone diverse (scuole, università, uffici)?
Hai idea che se basta cambiare una volta la password per non avere
problemi i PC realmente affetti sono un'esigua minoranza?


 e comunque un utente non locale
Si parla di exploit locali versus exploit remoti.
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 problemi i PC realmente affetti sono un'esigua minoranza?
il bug è gravissimo, punto è basta, inutile che ti arrampichi sugli specchi. 
Con i "se" non si va da nessuna parte. 

 severity della vulnerabilità.
sogna... sogna... 

Su tutta questa discussione mi viene di riflettere su alcune cose:
1. danni reali 'accaduti' causati dal bug?
2. tempo di individuazione e riparazione del bug?
3. nei grandi sistemi, centri le password di solito vengono a) cambiate 
periodicamente b) originariamente viene assegnata una pass provvisoria 
per poi essere cambiata;
4. il bug è grave e non arampichiamoci sugli specchi;
5. la sicurezza non è data solamente dal non verificarsi di eventi 
(impossibile) ma dalla pronteza di individuazione\risoluzione;
Saluti,
gp

 usato da tante persone diverse (scuole, università, uffici)?
se le installassi con l'utente amministrativo dell'installazione
di ubuntu (una tipica installazione desktop monoutente) sarei un
pirla, se lascio ALL in sudoers ad un utente sono un pirla con i
baffi, in generale, in ambiti simili non togliere significato ai
gain in locale e` male, sia  sotto win che sotto *ix x tua norma

P4 ha scritto:

Allora o sei scemo, o non sai leggere (secondo me tutte e 2)
Il bug c'era e siamo daccordo, quello che voglio dire io è che il 
problema si pone soltanto nel caso sulla macchina (desktop) esista un 
secondo utente (o più utenti) con privilegi limitati, allora si che 
questo utente potrebbe essere in grado di scalare i privilegi
Se sulla macchina esistono più utenti in grado di usare sudo, dovresti 
riuscire pure te a capire che il problema non esiste
La vulnerabilità esiste solo in locale, non è exploitabile dall'esterno, 
anche volendo del codice maligno in grado di sfruttare quel file 
dovrebbe venir eseguito dall'utente, cambiando la password all'utente il 
codice maligno, e il bug vanno a farsi fottere
Il bug, lo ripeto, è stato corretto in meno di 12 ore
Si trattava di un bug veramente cretino, su questo credo che saranno 
tutti daccordo con me
Luca

Riot@ct ha scritto:

Il bug è stato corretto in circa 12 ore,
Di danni non penso che ce ne siano stati, ubuntu è un sistema desktop, 
usato di solito da un singolo utente
Nei grandi sistemi, a parte che non so quanto sia usata ubuntu, e cmq 
spesso le password sono centralizzate (nis o ldap)
Luca

 root.
non e' vero
ciao,
--
oggei

 Luca

 usato di solito da un singolo utente
sogna ciccio... sogna...
http://www.ubuntu.com/
Ubuntu is suitable for both desktop and server use 

Rais ha scritto:

Peccato che:
1. ufficialmente la versione per server di ubuntu non è ancora uscita, 
ubuntu cmq è nata per il desktop
2. se vogliamo anche XP potrebbe fare da server
2.5 a proposito, ma anche in XP il db SAM delle password è leggibile da 
tutti per default? :-P
3. Il bug è già stato sistemato, e cmq basta cambiare la password per 
sistemare il problema (e chi amministra una macchina, specie server)
P4 stai facendo la figura del coglione come al solito....dai a noi puoi 
dirlo che hai 13 anni in realtà
Luca

 tutti daccordo con me
Dai tutti credo sia da escludere P4 (cloni compresi) naturalmente :-)
-- 
Ciao
Andrea Malfatti


ok, riformuliamo: in tutte le distro _sensate_ il log di installazione
viene salvato in /root/
Per esempio in Fedora/RedHat puoi guardare qui:
http://openskills.info/infobox.php?ID=1087
In Gentoo non c'e' install.log poiche' fino a ieri si installava a
manina.
Non capisco veramente il senso di creare l'install.log world readable.
-- 
Massimiliano


Chi ca$$o se ne frega UNO: ti pare che mi metto a perdere tempo a
guardare le bugtraq per andare appresso a P4?
Chi ca$$o se ne frega DUE: chi se ne fotte di bubuntu, kububuntu,
tatabuntu e ratabuntu.
Vi piace usare le distro alla moda e di cui tutti parlano? Pagate le
conseguenza: ergo ca$$i vostri.
Su RedHat/Fedora l'install.log e' in /root/ e cio e' cosa molto
sensata.
In Gentoo non c'e' install.log poiche' fino a ieri si installava a
manina.
-- 
Massimiliano

 tutti per default? :-P
FALSO.
Il SAM (a differenza di linux dove invece le password sono accessibili
direttamente da root da uno stupido file, criptato, però rubabile) NON
è direttamente accessibile da nessun utente, nemmeno dall'utente
administrator; solo i meccanismi interni di windows lo possono usare
ovvero solo il kernel di windows può usarlo.
1 - 0 per Windows.
Il SAM lo poi esportare se avvi da floppy o da un'altra partizione,
esattamente come in linux, solo che come in linux, anche in windows il
SAM è criptato.
1 - 1 
Saluti da P4

 SAM è criptato.
Per prima cosa il SAM lo puoi esportare senza partire con floppy ma
semplicemente facendone una copia con rdisk (ma ovviamente chi non sa
leggere difficilmente può sapere cose così ardue da trovare in Internet)
Secondariamente il file delle password di linux, che per tua
informazione normalmente è /etc/shadow, non è criptato ma è in chiaro.
L'unica protezione è che la sola password non è scritta in chiaro ma è
scritta come hash, normalmente md5 con salt ma a scelta anche sha1 con salt.
Come terza cosa diciamo che normalmente in Windows viene generato e
memorizzato anche l'hash LM, che è crackabile in meno di 5 minuti per
password fino a 8 caratteri con lettere numeri e punteggiatura (ovvero
il 99.9% dei casi). Con shadow il cracking non può essere effettuato se
non con la pura forza bruta.
Quindi totalizziamo un bel 3-0 a favore di Linux. Adesso però sparisci e
torna su icowx.


 ovvero solo il kernel di windows può usarlo.
Non parlare di cose che non capisci realmente, te ne prego.
Limitati a fare lo strillone, che così una qualche utilità 
l'hai.
Windows: documentati su pwdump e successori e poi riparliamone.
Linux: il file shadow contiene comunemente digest delle password
e non le stesse in forma crittata; ciò detto, con SELinux, ad esempio,
posso limitare come voglio l'accesso al file shadow.
Puoi andare, adesso.


 Windows che è suscettibile di cracking con rainbow tables.
Beh, in linea di principio non vedo grosse difficoltà
a costruire delle tables apposite per hash md5 a la shadow.


 ha scritto nel messaggio 
news:1142246020....@j52g2000cwj.googlegroups.com...
[CUT]
Ah porca paletta, adesso non dormirò più la notte.... perdindirindina, e chi 
se lo aspettava???
mavaiacagareva.... 

 a costruire delle tables apposite per hash md5 a la shadow.
Ehm... Ricordati che c'è il salt. Dovresti crearti delle tabelle per
ogni possibile salt. Considerando che le rainbow table fino a 8
caratteri occupano svariati GB, moltiplicare per i miliardi di possibili
salt non mi sembra molto attuabile.


 semplicemente facendone una copia con rdisk
Mi dispiace per te, ma rdisk era una vecchia utility per Windows NT 4 e
NON funziona più su Windows XP.
Saluti da P4

 salt non mi sembra molto attuabile.
si ma... seguendo le stronzate di P4 abbiamo detto che abbiamo accesso a
shadow ... e quindi il salt e li' e te lo leggi.
-- 
Massimiliano

 Windows il SAM è inaccessibile.
si ma, ca$$o, come ha gia' scritto whiplash, windump (che ho usato
personalmente per esportare le password su Samba) esegue il dump delle
password, dal registro di windows.
-- 
Massimiliano

 NON funziona più su Windows XP.
Opps che erroraccio...
Vorrà dire che su XP userò pwdump6.
Sparisci coglione.


 shadow ... e quindi il salt e li' e te lo leggi.
Scusa, ma sai cosa sono le rainbow tables?


 
Io non so cosa sia 'rainbow table'. Perdo punti se non lo so? ... piu'
tardi do un'occhiata per vedere cos'e'. Nel frattempo puoi rispondere
Mi era sembrato - e per favore correggimi se sbaglio - che tu stessi
partendo dall'assunto che tu non conoscevi il salt e io ho detto che il
salt, in questo specifico caso, lo conosciamo.
-- 
Massimiliano

 
http://www.spysystem.it/hacker_winnt.htm
Allora io che ho appena provato con l0phtcrack 5 sul mio pc (XP SP2) e 
ho letto in 4 secondi tutte le password sono un caso particolare?
/me perplesso =:-/
Luca


ROTFL: questo e' quel che riguarda rainbow table che ho trovato:
Ptable = 1 −t Yi=1 (1 − mi N) (3)
where m1 = m and mn+1 = N  1 − e−mn N  
Lasciamo stare e non mi parlare come se tu fossi l'inventore di questi
algoritmi. Qui il discorso e' che tu conosci il salt, e che
probabilmente in qualche modo puoi utilizzare questo dato.
E' chiaro che e' vero quello che si dice: nei normali attacchi tu non
conosci il salt (poiche' si presume non hai accesso al file shadow) e
non puoi trarre benefici da questo metodo.
-- 
Massimiliano

 salt, in questo specifico caso, lo conosciamo.
No. Il fatto che vi sia un salt, a prescindere dal fatto di conoscerlo,
impedisce determinate tipologie di cracking delle password, possibili
invece con quella sottospecie di algoritmo di hashing di Windows.


 invece con quella sottospecie di algoritmo di hashing di Windows.
onesto: stai parlando di come funzionano i toolettini vari o di come
funziona l'algoritmo?
Anche io ho letto che usando quel metodo non si traggono benefici se la
password usa il salt, perche' di norma, non si conosce il salt. Ma e'
possibile riscrivere il toolettino per dargli in pasto il salt?
-- 
Massimiliano

 Saluti da P4
Suca
-- 
Gordon Freeman, Linux User #332250 on attila, Linux Machine #305615.
http://www.counter.li.org/
http://www.slackware.com/getslack/
 

 ovvero solo il kernel di windows può usarlo.
Oppure da chiunque bootando una distro Live.
Security through obscurity, in pratica.
ciao, f.

 e' possibile riscrivere il toolettino per dargli in pasto il salt?
Te lo spiego per bene.
Il metodo delle rainbow table funziona mediante il precalcolo di tutti
gli hash possibili ed eseguendo quindi una ricerca della password a
partire dagli hash. Ovviamente questo significa che se la password con
il relativo hash è incluso nella tabella, il cracking richiede solo il
tempo di ricerca dell'hash nella tabella.
Il metodo però funziona solo se la relazione tra password e hash è
biunivoca.
Questo nel caso di hash con salt è vero SOLO se il salt è costante. Su
linux il salt cambia casualmente, quindi alla stessa password
corrisponde un hash diverso per ogni salt.
Per verificarlo basta che provi a settare la stessa password a due
diversi utenti su linux e verificare il relativo hash nel file shadow.
Nel caso dell'md5 l'hash occupa 128 bit, ovvero 16 bytes. Ogni record
della tabella occupa quindi 16byte + la password. Una rainbow table per
le sole lettere minuscole, maiuscole e numeri, con password fino a 8
caratteri è composta di 221.919.451.578.090 records, quindi occupa
teoricamente 5.326.066.837.874.160 bytes. Nella realtà i record vengono
impacchettati ed occupano molto meno spazio, ma richiedono comunque
parecchi gigabyte.
Dato che però la presenza di un salt rende la relazione password<=>hash
non biunivoca, è necessario calcolare una rainbow table per ogni singolo
valore del salt. Nel file shadow il salt può avere 218.340.105.584.896
differenti valori, per cui sarebbero necessarie altrettante tabelle,
cosa che rende non conveniente l'uso delle rainbow table rispetto
all'attacco diretto perforza bruta.


 valore del salt. 
si ma infatti... ripeto: tu conosci il salt, pertanto la corrispondenza
e' biunivoca :)
-- 
Massimiliano

 e' biunivoca :)
Allora non hai capito *nulla* di tutto il discorso. Sorry.


 
Zip, espanditi e ragiona.
E' chiaro che se non conosci il salt vale certamente il tuo discorso.
Ma la difficolta' apportata dall'esistenza del salt, sussiste solo se tu
il salt non lo conosci.
Ti ho gia' detto che se tu usi lo stesso salt e la stessa password,
l'hash sara' sempre uguale.
altrimenti come caaaaaazzo fai a fare login?
Se tu conosci il salt, il salt non serve piu' a niente.
-- 
Massimiliano

 E' chiaro che se non conosci il salt vale certamente il tuo discorso.
Ti ripeto che non c'entra nulla con il discorso. Si è partiti dal fatto
che la presenza del salt impedisce il cracking tramite l'uso di rainbow
tables. Il cracking per forza bruta è SEMPRE possibile avendo lo shadow.


 
Matematicamente parlando, hai sparato una puttanta di dimensioni
apocalittiche.
La biunivocità è una caratteristica di una funzione, o applicazione
vettoriale, che NON si addice proprio a crypt(), che, per definizione, è
UNIVOCA. E meno male che lo è.
f(pass,salt) => hash
l'incontrario è impossibile.
Max

 ma FF NON è più sicuro di IE6 SP2
Peccato. La tua amata Symantec afferma il contrario.
http://punto-informatico.it/p.asp?i=58325&r=PI


 E meno male che linux doveva essere sicuro... :-)
Lo e'....di sicuro piu' di Windows XPire
Buh

 Zip, espanditi e ragiona.
MA LOL !!!!
f.

 
http://punto-informatico.it/p.asp?i=58325&r=PI
in questo momento forse il peggio e` safari, comunque ;)

 Windows che è suscettibile di cracking con rainbow tables.
Il concetto di rainbow table mi fa ritornare in mente una vecchia idea 
che avevo per realizzare un protocollo per trasmissione di dati con 
compressione incorporata. In pratica l'idea e` quella di avere gia` i 
dati dall'altra parte (enormi tabelle precalcolate) e di trasmettere 
solo gli hash (magari con due algoritmi diversi per evitare collisioni) 
di un blocco di N byte. Nel caso che l'hash non sia presente nelle 
tabelle del ricevente, quest'ultimo puo` rispondere con un NAK ed il 
trasmittente gli manda il blocco di dati di N byte per intero. Una volta 
fatto questo il ricevente puo` aggiornarsi le tabelle con questo nuovo 
blocco (e quindi calcolarsi l'hash).
Tutto questo potrebbe funzionare bene per la trasmissione di video, che 
hanno molta informazione in comune tra una frame e l'altro. Nel caso di 
video prodotti da un sistema di videosorveglianza l'efficienza sarebbe 
ancora maggiore, essendo il video formato da immagini che hanno molto di 
ripetitivo.
Sto sbagliando qualcosa ?
-- 
Vincenzo

 Ehm... Ricordati che c'è il salt.
Ok, ok...*piccola* dimenticanza. :-)
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 UNIVOCA. E meno male che lo è.
No, crypt() è invertibile.
E' l'hashing md5 che, in generale, è una funzione non biunivoca.


 E' l'hashing md5 che, in generale, è una funzione non biunivoca.
Allora chiedo scusa a max, cistoche la puttanata l'ho sparata io.

 UNIVOCA. E meno male che lo è.
Hai perfettissimamente ragione e me ne sono accorto _SUBITO_ dopo aver
inviato il messaggio: la corrispondenza _non_ e' biunivoca. Un hash
senza collisioni matematicamente non esiste e bla bla .... cmq basta
non ci impelaghiamo in discussioni matematiche :)
-- 
Massimiliano

 tables. Il cracking per forza bruta è SEMPRE possibile avendo lo shadow.
Zip: piantala per favore.
Spero che tu abbia capito e che adesso tu stia solo cercando di
mischiaew le carte.
Tu hai detto: la presenza del salt rende quasi impossibile l'uso di
quel tool.
Io ho detto: se il salt lo conosci, puoi riscrivere il tool dicendogli
di far uso del salt.
Se questo non ti e' chiaro, documentati.
Io aggiungo un'altra cosa. Con quel sistema che mi hai descritto tu
(che io non conoscevo) "rischi" di trovare, non tanto la password
(forse anche quella), quanto una collisione... ovvero potresti trovare
una password diversa che produce lo stesso hash.
Se qualcosa non ti e' chiaro dimmelo, posso indirizzarti su qualche
buona lettura.
-- 
Massimiliano


LOL, sarebbe a dire che ti stavo per dare ragione e invece ho ragione?
ri-LOL :) :)
-- 
Massimiliano

 di far uso del salt.
Le dimensioni delle tavole ed i tempi di generazione delle stesse
sarebbero tali da non risultare economici.
Così ti è più chiaro?


 Ok, ok...*piccola* dimenticanza. :-)
whiplash, ho trovato questo, documento che conferma che ho detto una
una cosa esatta:
--> if the attaccker DOESN'T have the salt !!
If they attacker just stole your hash then what it really depends on is
the charset, more than anything else, because all those online rainbow
tables (i.e. 
md5.rednoize.com
 or one of the IRC bots like C3PO on
#rainbowcrack at 
irc.governmentsecurity.org
), generally operate on
limited charactersets. And if you salted your passwords when storing
them (and the attacker doesn't have the salt, if the salt has weird
characters like Unicode characters, or Control characters, then thats
even better), then the likelyhood of them finding anything by rainbow
tables or dictionaries (without knowing the hash of course, and if
you've got a seperate hash for each user....) is very limited.
http://forums.devshed.com/security-and-cryptography-17/password-strength-analyser-329413.html
-- 
Massimiliano

 Così ti è più chiaro?
Leggi qui, quello che ho trovato:


 buona lettura.
Forse quello che deve fare qualche lettura sei tu caro mio.


 Max, piantala per favore.
sperando che lameno capisci l'inglese:


 
http://punto-informatico.it/p.asp?i=58325&r=PI
"Per ottenere lo stesso risultato con Windows, gli esperti di Symantec hanno
dovuto applicare tutte le patch di sicurezza rilasciate fino a quel momento
da Microsoft". Ovvio che se fanno il confronto non applicando tutte le patch
fin'ora disponibili... 

 Sto sbagliando qualcosa ?
Nella teoria direi di no, ma nella pratica non so quanto possa essere
conveniente rispetto alla trasmissione dell'intero flusso video MPEG2/4
che già sfrutta un meccanismo simile (nel senso che dei frame vengono
trasmesse le differenze).


 sperando che lameno capisci l'inglese:
Sě, č solo la mia speranza che tu capissi qualcosa dell'argomento che
ormai č sotterrata.
E sě che bastava anche solo leggere la wikipedia per capire.
Ora basta. Plonk.


 fin'ora disponibili... 
Continua a fare lo scemo tagliando le parti rilevanti del discorso....
Il paragone era tra RH e SuSE *non* patchate e windows non patchato,
quindi era ad *armi* *pari*.


 Ora basta. Plonk.
Deficiente.
Per evitare che la tua disinformazione vada avanti ri-posto e spiego:
1) wikipedia e tutti gli altri dcono una cosa giustissima: se la
passwords e' "saltata" il numero di combinazioni aumenta
vertiginosamente. Questo e' ovvio e sensato da dire quando si parla di
attacco, poiche' _tutti_ presumono che un attacker stia provando a
bucare una macchina sulla quale non e' ancora entrato da root, ovvero
una macchina dove "shadow" non e' stato letto.
2) il concetto da chiarire e' che se tu hai accesso a "shadow" vuol
dire che sei root su quella macchina, o che quella macchina e' bucata.
Pertanto non ha alcun senso una protezione ulteriore in questo caso: se
tu sei root cambi le password. Che senso ha vole bucare una macchina
dove sei dentro come root?
3) Ripeto quel post in inglese: And if you salted your passwords when
storing
them (and the attacker doesn't have the salt, if the salt has weird
characters like Unicode characters, or Control characters, then thats
even better),  then the likelyhood of them finding anything by rainbow
tables or dictionaries (without knowing the hash of course, and if
you've got a seperate hash for each user....) is very limited.
-- 
Massimiliano

 di far uso del salt.
Il metodo di utilizzo del salt è più o meno il seguente:
Salt := ValoreCasuale(TotLettere)
PasswordCifrata:=md5(salt & md5(PasswordInChiaro));
Le rainbow table devono essere *pre*calcolate e lo devi fare *per ogni*
salt, va da sè che è un compito quasi impossibile per via della casualità
del salt stesso.
Se tu conosci un salt particolare, quindi di un preciso utente, è possibile
con una rainbow table ad hoc trovare la password? Perchè?
Certamente non è possbile fare il ragionamento generale (e quindi usare un
rainbow table preconfezionata) proprio perchè il salt è variabile.
bye, Giubbe

 dove sei dentro come root?
Se le tue macchine le proteggi partendo da questi presupposti, non
vorrei mai dover dipendere dai tuoi servigi.
Piantala per cortesia?


>kernel di windows
ah perke bill ha creato anke il kernel?......hahahaha

 
Vedi che sei idiota? prima dici che c'è un *gravissimo bug in ubuntu* e 
quindi deduci che linux è insicuro; poi pontifichi sul fatto che di 
distribuzioni ce ne sono milioni... QUindi tutte le distribuzioni hanno 
quell'erroraccio, right?
Altrimenti hai (come al solito) cappellato
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Ho letto nel "Reader's Digest" che le sigarette fanno male.
Cosi' ho subito smesso di leggere il "Reader's Digest".
		-- Anonimo

 Piantala per cortesia
Misteriosamente, adamo è scomparso.
Che abbia preso coscienza, col delay che gli si addice, della
figura barbina che ha fatto? <g>


 Non capisco veramente il senso di creare l'install.log world readable.
il problema e' che nei log non ci va una fava che non sia un log, e'
come la gente che butta le plastichine delle sigarette nel posacenere.
il file ha senso, invece, che sia world readable cosi' come ha senso che
man chroot lo possa fare chiunque
ciao,
--
oggei

 ah perke bill ha creato anke il kernel?......hahahaha
sei uno stupido.
ciao,
--
oggei

Ah Ah Ah Ah Ah, anche linux Debian ha lo stesso bug!!!!
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356939
E meno male che linux doveva essere sicuro... :-)
Saluti da P4

P4 ha scritto:

sei un povero idiota
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Un uomo sulla luna non sara' mai interessante quanto una donna sotto il
sole.
		-- Leopold Fechtner

 sei un povero idiota
Description:
Joey Hess has reported a vulnerability in Debian, which can be
exploited by malicious, local users to disclose sensitive information.
The problem is caused due to user credentials being written to
world-readable installation log files during installation. This can be
exploited to disclose the preseeded password of root and other users if
a preseed file is used for an automated install, and the pppoeconf
passwords in the base-config log file.
The vulnerability has been reported in version 4.0.3-31sarge5 and
4.0.14-7 of the shadow package, and version 2.53.10 of the base-config
package.


Non si deve aspettare il prossimo piano quinquennale a la M$
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Vivere nel paese dei campanelli e' un vero supplizio per chi ama bussare.
		-- Alessandro Bergonzoni

 è già stato fixato.....
E allora? Non ne dobbiamo parlare? Non c'è stato? Non è grave? In
quanti hanno già aggiornato? Quante password nel frattempo sono state
rubate?
Saluti da P4

 Quante password nel frattempo sono state rubate?
Pochissime perché non è comune avere molti utenti che accedono ai server
(essendo appunto server), e perché ove vi sono utenti che accedono via
shell le password impostate in fase di installazione sono generalmente
cambiate (non essendovi impedimenti come spesso avviene in Windows).


 rubate?
ROTFL!
al primo login come root quel file lo vedi, sai che non serve ad un cazzo e
che contiene le pass e lo pialli.
Io ho sempre fatto così, ed è buona norma che un sistemista controlli il
sistema.
Su unix si fa, su winblows si lascia spesso l'utente guest, pensa un pò.
Max

 Tra quelli che io conosco tutti.
La falla su Debian è stata riportata ieri 14 marzo. Oggi è il 16, e
tu sai già che tutti quelli che conosci hanno già patchato? Sei
ridicolo oltre che falso.
Secunia dice che non è ancora stato patchato: "Solution Status:
Unpatched" è che SARA' patchato nella 4.0.14-9
http://secunia.com/advisories/19170/
Quindi o l'hanno patchato ieri o oggi, quindi avere la presunzione che
tutti l'hanno già messa, mi pare un tantino azzardata come cosa...
Saluti da P4