Newsgroup: it.comp.os.dibattiti
Titolo: Un paio di riflessioni sulla sicurezza

Ciao a tutti
Oggi dopo circa un mese che non me ne occupavo ho deciso di installare
su un server che amministro tutte le patch di sicurezza necessarie.
Il server per la cronaca e' una debian 2.1
Sono rimasto un poco perplesso:
In circa un mese ,un mese e mezzo, si sono scoperti circa 6 bug di
sicurezza in programmi che uso su quel server.
Non erano tutti gravi, ma un paio potevano portare un utente non
autorizzato, senza troppe difficolta', ad avere i permessi di root.
La cosa che piu' mi "sconvolge" e' che sono SEMPRE gli stessi errori
di programmazione che si ripetono in programmi differenti e che
essendoci i sorgenti in circolazione non e' nemmeno troppo difficile
trovarli.
Quindi le mie riflessioni:
1)Credo che sarebbe una buona cosa implementare a livello di sistema
operativo una granularita' di permessi molto fine, e diversificarla
per tutti i programmi.
Mi spiego meglio:
Io scrivo il programma xy che deve solo scrivere dei file sulla tmp ed
un file di configurazione nella home dir dell'utente chiamato .xy, e
non deve effettuare connessioni ad internet e deve usare non piu' di
1M di ram.
Bene, allora impongo che il SO di a questo programma ESCLUSIVAMENTE
questi permessi.
In questa maniera se faccio un errore di programmazione questo puo'
avere effetti molto limitati.
E' un qualche cosa di simile alla sandbox di Java.Credo che questo
sia, con tutti i dettagli definiti, un approccio strutturale
interessante e che potrebbe aumentare fortemente la sicurezza dei
sistemi.
Certamente non e' di facile e veloce implementazione e puo' anche
avere un impatto sulle performance non indifferente. Sapete se esiste
qualche sistema di nicchia o sperimentale che e' fatto in modo simile
a quello da me descritto?
2)Siete sicuri che il fatto che i sorgenti di molti programmi siano
disponibili a tutti sia una cosa buona PER LA SICUREZZA? Credo che i
programmi sarebbero sicuramente meno sicuri se i sorgenti non fossero
disponibili ma sarebbe ENORMEMENTE piu' difficile scoprirli.
Per esempio credo che sarebbe  difficile scoprire un buffer overflow
senza sorgenti.
Saluti
Mamo




PS 
Mi scuso per aver postato il messaggio due volte ma ho avuto problemi
con le regole di posting della gerarchia it.*

 senza sorgenti.
piu' che altro io mi stavo domandando una cosa.
supponiamo che Hadrew Ballerman (nome totalmente inventato) sviluppi un
programma di posta elettronica (per esempio) e che non ne distribuisca i
sorgenti (oppure li distribuisca ma rendendo alcune parti molto
"offuscate"... tipo 
www.ioccc.org
)
Il programma, oltre a fare quello che deve fare, cambia subdolamente parte
del sorgente del kernel di linux in modo da creare una backdoor (ovviamente
se il sorgente e' stato installato).
Cosa succede ad una ipotetica successiva compilaizone del kernel?
backdoor creata?
se cosi' e' , mi sembra un attimino pericoloso il sistema...

overflow senza sorgenti.
Non credo che sia *troppo* difficile. Con un disassemblatore
puoi riconoscere tranquillamente le API di windows, e sai
quali accettano stringhe come parametri. Non è difficile
nemmeno vedere quando si accede ad una stringa.
Ci sono tools come SoftIce che permettono ai cracker
di fare meraviglie. Trovare un buffer overflow in un binario
credo che non sia poi tanto più difficile che scrivere
un generatore di chiavi per uno shareware.
P.S.
Quando alla mattina arrivo in ufficio, per prima cosa guardo
bugtraq. Per seconda cosa verifico se RedHat ha "prodotto"
qualcosa per me. Se c'è una patch la scarico comunque e,
se riguarda qualcosa che uso, la installo. Meglio perdere
dieci minuti al giorno che dieci giorni in un minuto.

se il sorgente e' stato installato).
1) Non hai fatto una grossa scoperta: si chiamano cavalli
di troia. Hai presente backorifice? Su windows funziona che è
una meraviglia.
2) Fammi capire: tu installi qualunque cosa scarichi dal web?
3) Modificare il codice di un qualsiasi kernel non è così banale:
quale versione? per quale piattaforma? in quale modulo?
in quale directory?
4) Quanto tempo pensi che ci si metterebbe per scoprire
l'inganno? Credi che l'autore di una simile azione non
sarebbe perseguito penalmente?
5) Solo un perfetto imbecille eseguirebbe del codice scritto
da un emerito sconosciuto con privilegi di root
6) ragazzo, tu hai dei seri pregiudizi sul software free.
Guarda che non è codice tenuto insieme dallo sputo e
scritto da qualche ragazzotto imbecille. Non è che chiunque
installi qualunque cosa solo perchè tanto ci sono i sorgenti.
Le applicazioni che usiamo hanno un nome ed una persona
od un gruppo di persone che la mantiene, cui si può far
riferimento. Questa cosa si chiama "fiducia", ed è la stessa
che tu riponi in Microsoft o Adobe quando installi uno
dei loro prodotti. Qualunque nuova applicazione sconosciuta
viene guardata con lo stesso sospetto che hai tu (spero per te)
quando scarichi l'ennesimo gadget da mettere sulla tray bar,
e viene presa in considerazione in ambienti "produttivi" solo
quando i test di centinaia di utenti hanno mostrato che
è stabile e sicura.
7) lasciamo stare la stronzata sul codice offuscato: ti sei
mai preso la briga di guardare come sono scritti i sorgenti
di un'applicazione free?

 con le regole di posting della gerarchia it.*
una gestione così restrittiva dei permessi è decisamente limitante...
per quanto riguarda la disponibilità dei sorgenti... beh, è un arma a
doppio taglio... in effetti è più semplice individuare bugs come gli
overflow dei baffer... ma dopo un certo periodo di vita un software di
cui sono disponibili i sorgenti (pensa allo stesso kernel anche se non è
propriamente software) diventa decisamente più robusto...
che ne pensate? io sono per i sorgenti!
-- 
  _     _                                  _ 
 (_)   | |                                | |
  _____| |  ___   ____    ____  _____   __| |
 |  _   _) / _ \ |  _ \  / ___)(____ | / _  |
 | |  \ \ | |_| || | | || |    / ___ |( (_| |
 |_|   \_) \___/ |_| |_||_|    \_____| \____|

 di un'applicazione free?
proprio non hai capito...
lo so come si scrivono i sorgenti, ma so anche che se uno vuole in C++ o in
C puo' scrivere un programma funzionante che ha la forma di un trenino o di
una palla o di una scritta a caratteri cubitali
oppure, senza tanta fantasia, puoi "offuscare" codice senza renderlo tanto
coreografico...

 disponibili a tutti sia una cosa buona PER LA SICUREZZA?
Si` :-)
-- 
Che sonno!                                                   _/Davide\_
                                                             \Alberani/

se cosi' e' , mi sembra un attimino pericoloso il sistema...
Che domande...
L'installazione dei programmi e' riservata a root, quindi la responsabilita'
e' solo sua. Tradotto: se l'admin e' stupido c'e' poco da fare.
In ogni caso l'autenticita' dei pacchetti .deb (non conosco gli rpm) e'
garantita da un hash MD5. Basta stare attenti.
ps. Ti senti sicuro quando installi software m$ con tutti quei bei
easter eggs?
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(per rispondere via email fai un rot13 dell'indirizzo)
(apply a rot13 to reply)

senza sorgenti.
Considera però che la maggior parte delle persone che leggono i sorgenti,
lo fanno per <<nobili fini>>, nel senso che poi quando scoprono qualche
baco di sicurezza preferiscono risolverlo e comunicarlo allo sviluppatore
che non provare a fare i furbi, mentre con altri ambienti/S.O. succede
esattamente il contrario :-)
E poi, un malintenzionato *capace* non si fa scoraggiare dal non avere
sorgenti (che potrebbe anche procurarsi in modo illecito), e nell'ipotesi
dei sorgenti "segreti" si troverebbe a stressare un programma che è
molto probabilmente più debole di uno che ha passato il vaglio di più
teste.
Un po' come nella crittografia, per cui oggi tutti credono in algoritmi
pubblici che basano la loro forza sulla segretezza della chiave, e non
sulla segretezza dell'algoritmo che è anzi in genere indice di
inaffidabilità.
Per cui, ci sono più fatti positivi che fatti negativi nella politica dei
sorgenti pubblici, anche se qualche ombra può esserci: ma nessuno
pensa di scrivere programmi senza bug ;-)


Il server in questione e' amministrato a livello amatoriale in una
universita'.
Per dirla in altri termini NUN ME PAGANO.
Quindi siccome sono andato un mese in vacanza e prima della vacanza
dovevo studiare per un esame non ho visto i bug che erano usciti in
quel periodo.
Ciao 
Mamo

 senza sorgenti.
 Si.
 a) se qualcuno scopre un buco di sicurezza, puo' usarlo senza che
nessun altro possa scoprirlo
 b) chi ti sistema il buco di sicurezza?

 senza sorgenti.
E' vero, ma sarebbe anche difficile creare le patch, perché meno gente
ci metterebbe le mani, no?
-- 
Non c'è più forza nella normalità: c'è solo monotonia.

 limitare i programmi ad accedere solo a certe risorse
Non lo sapevo. Non posso che osservare che sarebbe una cosa molto
intelligente e che mi ha sorpreso in positivo.
Credo che sarebbe il primo sistema operativo diffusamente usato ad
avere caratteristiche di questo tipo.
Ciao
Mamo
 

 limitare i programmi ad accedere solo a certe risorse.
Mi potresti dare qualche dettaglio in piu perche' ho cercato tra le
nuove caratteristiche del kernel senza trovare nulla.
C'e' solo una lista di periferiche nuove supportate e nulla piu'.
Se mi spieghi questa tecnologia brevemente e mi dai un puntatore per
approfondire mi fai un piacere.
Ciao a tutti
Mamo

disponibili a tutti sia una cosa buona PER LA SICUREZZA? Credo che i
Si se il numero di persone che cerca i problemi nei programmi per
metterli a posto e' superiore a quello di chi cerca i bug solo per
fare casini. Quindi SI senza dubbi.
-- 
Ciao
     Marco Innocenti

senza sorgenti.
Rispondo con una domanda ... Siamo sicuri che NON divulgando i src la
sicurezza aumenti o al limite le patch ai prbl. trovati siano
rilasciate in un tempo accettabile ?
[Hint: Un esempio notevole e' sotto gli occhi di tutti ...]
Ciao, MaRcO
================================================================
"Take My hand, I'll lead You to the promised Land ...", I.Maiden

senza sorgenti.
Su questo ho i miei dubbi, ci sono programmi scritti apposta per
testari i problemi di buffer overflow, come gli ultimi hack di IIS
hanno dimostrato.
Meglio i sorgenti, almeno puoi applicare la patch in 5 minuti.

>Per dirla in altri termini NUN ME PAGANO.
Nel qual caso: se hanno problemi di sicurezza ... CAZZI LORO !
O no?

senza sorgenti.
Dici? Io ho uno script che cerca buffer overflows nei programmi MS, e
MS i sorgenti di quei programmi non me li ha dati.
In questo modo io i buffer overflow li trovo, l'exploit ce l'ho, e tu
la soluzione non la puoi avere <bwahahahahaha>.
Ho anche uno scriptino idiota che cerca buffer overflows nei sorgenti
dei programmi Linux, cosi' li puoi tappare. In genere individua molte
righe che non sono buffer overflows, ma potrebbero esserlo in strane,
o anche impossibili, circostanze (per es.:
	if (1+1 == 5)
	{
		buffer_overflow();
	}
). Si basa sulla ricerca delle funzioni tipicamente usate nei B.O.F.,
cioe' strcpy, strcat, sprintf, vsprintf, memcpy eccetera.
Leonardo
".signature": bad command or file name


m> 2)Siete sicuri che il fatto che i sorgenti di molti programmi siano
m> disponibili a tutti sia una cosa buona PER LA SICUREZZA? Credo che i
m> programmi sarebbero sicuramente meno sicuri se i sorgenti non fossero
m> disponibili ma sarebbe ENORMEMENTE piu' difficile scoprirli.
naaaa, l'esperienza insegna che, la' dove c'e' un bug, c'e' sempre un
hacker pronto a scoprirlo. Basta dare un'occhiata a una ML come
bugtraq per rendersi conto di quanti ne vengano trovati, con o senza
sorgenti.
-- 
ciao,
Claudio

coreografico...
Magari compilandolo anche e distribuendolo solo in quella forma.
Piů offuscato di cosě...

Divertitevi:
http://www.tiac.net/users/smiths/acctroj/index.htm

se cosi' e' , mi sembra un attimino pericoloso il sistema...
Direi di no - la situazione peggiore e' negli SO commerciali dove
*tutti* i programmi possono potenzialmente essere come dici tu (ovvero
contenere una backdoor).
Invece in un sistema OpenSource puoi sempre controllare il sorgente e
vedere che non ci siano "stranezze" (se lo sai fare e se la sicurezza
del sistema e' per te importante, altrimenti cambi programma e basta).
-- 
The Hitman - 
http://utenti.tripod.it/hitman_hp/
Fan #1 di Ruri Shiromizu 
Moderatore di it.comp.software.browser.
"Don't belive in anything that you can't waste" - G

una palla o di una scritta a caratteri cubitali
Il giorno che io installero' del software di una persona irrintracciabile, O
scritto in forma di trenino, su un sistema del quale me ne fregasse qualcosa
(per i nemici giurati e' diverso), spero che qualche amico pietoso mi uccida
senza farmi soffrire, perche' evidentemente avro' perso il senno.
Ripensandoci, diciamo "senza farmi soffrire, se ci riesce, se no pazienza"
Leonardo che in certi casi e' bene non andare per il sottile
Microsoft Outlook: cosa vuoi postare postare postare oggi?

nuove caratteristiche del kernel senza trovare nulla.
Infatti fanno parte delle VECCHIE caratteristiche :-). Prova a fare
"man chroot" o "chroot" senza parametri.
Leonardo


 senza sorgenti.
Mmmm sempre la solita solfa... 
Con i sorgenti li puoi fissare tu direttamente in attesa del fix ufficiale,
senza no. E poi e' meglio che possano essere trovati da tutti... cosi' sei
obbligato a fare upgrade del tuo sistema.
bye
Gianluca
---
Check my home pages for my free software for Linux 
http://www.geocities.com/SiliconValley/Code/3590/
http://members.xoom.com/chewbegm/

garantita da un hash MD5.
Idem con patate per gli RPM (MD5/PGP)

 Ripensandoci, diciamo "senza farmi soffrire, se ci riesce, se no pazienza"
Certo, certo... 30 ml di morfina, prima...
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Si, ma e' un'ipotesi abbastanza remota. 
La cosa migliore e' attivare la backdoor nel compilatore. Cioe', tu
il copilatore per forza di cose lo devi avere gia' eseguibile, ma non sai
che il tuo compilatore quando compila inserisce cavalli di troia _e_ fa' in
modo che quando compili un compilatore (Perche' non ti fidavi di quello gia'
fornito in forma binaria), nel compilatore viene compilata pure la parte per
generare i cavalli di troia e per riprodursi ...
-- 
                                                                     __
 __                                                              _  ///
| _        Student in Computer Science, Swiss Federal Institute  \\///
|__|iambo      of Technology - mailto:
ggia...@iiic.ethz.ch
       \X/

Ciao Mamo,
Beh non sono molto d'accordo con te per due motivi anzi 3.
il primo e' che conoscere il sistema operativo che usi a livello di codice
sorgente o comunque una piccola infarinatura che ti permette di
destreggiarti abilmente e' fondamentale per non farsi addormentare il
cervello. Troppi coders sono abituati al mondo Microsoft dove TUTTO e'
visuale e nessuno sa che ci sta dentro la famosa
kernel32.dll.
Il secondo e' che nonostante che escano advisory e exploits MOLTO ma MOLTO
tempo dopo che questi sono effettivamente scritti, sia le case costruttrici
sia gli amministratori difficilmente pongono rimedio ai bugs del proprio
sistema.
Da una recente indagine su un parco macchine SGI - IRIX di 12000 stazioni di
lavoro di una famosa industria di semiconduttori, ne sono risultate
exploitabili DA REMOTO circa 6000. Tramite un bug uscito nel 1997.
Bug tuttora NON patchato dalla SGI. non dico bug e industria ma per saperne
di + potete tranquillamente scrivermi.
Tu sei un admin coscienzioso ... ma altri evidentemente NO.
Kuali sono i sistemi operativi + seguiti e curati ? Linux, BSD, e gli open
source in genere.
Non a caso l'SGI ha scelto ora come ora di abbandonare IRIX per le proprie
workstation per passare a Linux.
Non far vedere il codice secondo me e' come dire .. si il mio codice e'
malato ... ma nessuno lo vede, nessuno puo' sfruttarlo ... e quindi sto
tranquillo.
( come il famoso guanto che si mette nella mano con la scabbia per non far
vedere a nessuno che sei malato ).
Terza cosa : ci sono sistemi operativi UNIX molto + difficili da "cracckare"
che altri, vedi BSD ad esempio, NetBSD e FreeBSD, con particolari attenzioni
per la security, penso sia inutile in sostanza nascondere il proprio codice
per motivi di sicurezza ... alla microsoft non e' servito .. vedi i recenti
"lavori" degli ADM al CCC meeting di Berlino.
Quarta cosa : ( non era prevista ) mi dici come ci divertiremmo noi e gli
altri cattivi della rete se tutto fosse nascosto ? sarebbe molto + difficile
... ahah ahah ahh ahah a hahah.
abbracci e scusa per l'auto ironia.
                                                                PhoenYx
quetzacoa...@usa.net
                            e spero presto
pho...@ordadellebadlands.org

senza sorgenti.
vedi sopra ;)
invy 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------

 con le regole di posting della gerarchia it.
...e io mi scuso con il ritardo , ma, dopo le vacanze ho un arretrato
pazzesco, sia di lavoro che di post.
Ciao,
	Ermanno Polli che posta in trasferta, mentre attende che un (bel
po') di gzip finiscano il loro compito...

 un sistema proprietario e quindi in via di estinzione. :-(((
Perň vaglielo a spiegare che quel coso in via di estinzione č anni luce
avanti al
loro amato giocattolino ....x.
Saluti.

senza sorgenti.
E' uno dei fondamenti della crittografia (è un principio che porta il
nome di qualcuno che adesso mi sfugge): la sicurezza di un sistema di
criptazione sta nella segretezza della chiave e non in quella del
codice. Tenere segreto il codice impedisce, anzi, ritarda la scoperta
dei bug e dei buchi di sicurezza, ma una volta che un intruso abbia
violato la corazza del programma, praticamente agisce indisturbato.
Credo che per il software valga qualcosa di simile a quello che
succede per i prog di criptazione. Daccordo, con il sorgente
disponibile tutti fanno prima ad accorgersi dell'esistenza di un
buffer overflow. Ma tieni conto di questo:
1. Se esiste un buffer overflow, con il sorgente disponibile, se ne
accorgeranno senz'altro i malintenzionati, ma non c'è dubbio che se ne
accorgeranno anche gli sviluppatori. Cioè, mediamente, i bug vivono di
meno. Il prezzo è che ci se ne accorga molto presto. Lo ritieni un
fatto negativo? Credi che l'alternativa a correggere immediatamente i
bug sia nascondere il più possibile il codice in modo che il bug
permanga più a lungo nel programma ma senza che nessuno lo sappia? Io
credo che il sorgente libero favorisca la scoperta di bug (da parte di
tutti, malintenzionati compresi), ma che il punto cruciale sia che i
bug hanno vita molto più corta. Bene che sono stati trovati 4 bug in
una settimana: preferivi tenerteli e non saperlo?
2. Il buffer ovrflow, sorgente o non sorgente, c'è comunque. Con la
differenza che se il sorgente non è disponibile il malintenzionato
potrà approfittare di una situazione dal suo punto di vista
*doppiamente* conveniente: l'esistenza del bug e l'ignoranza sulla sua
esistenza. Agisco molto meglio se conosco una falla del programma e
nessun altro (o pochi) sanno come funziona intimamente il programma.
Per di più, l'utente, che auspica che il programma sia sicuro, non può
che attendere che la software house ripari il danno: vale a dire,
accetta i lunghissimi tempi di attesa, tenendosi nel frattempo un
prog. insicuro.
Se invece io, sviluppatore, conosco come è fatto il sorgente,
interpreto immediatamente i malfunzionamenti del programma a seguito
di un'azione di un malintenzionato, e individuo la falla: in pratica,
paradossalmente, l'azione dei malintenzionati aiuta ad individuare il
buco e a proteggere il programma dai malintenzionati stessi.
3. Una volta raggiunti dei buoni requisiti di sicurezza per un
software, nasconderne il sorgente costringe gli sviluppatori di altro
software a reinventare tutte le volte la ruota: lamenti il fatto che
gira gira i buchi di sicurezza sono sempre i soliti, nei vari prog;
ecco, con i sorgenti non liberi la situazione sarebbe ancora peggio.
Mostrare il sorgente (con i suoi buchi e le sue soluzioni sicure),
aiuta gli altri software a non generare gli stessi buchi (almeno in
teroria :-)
Topoldo
(Grazie a Dio, sono ateo)