Vulnerabilita` dei kernel attuali

[d4z_c0nf]

Io uso solo kernel standard e niente RHEL o derivate
Anyway, alla luce di queste vulnerabilità (che poi, sinceramente, mi sembrano vulnerabilità fino a un certo punto.. mah) che saltan fuori, non ritenete che il sorgente aperto sia fondamentalmente un rischio e non già un vantaggio per la sicurezza??? Tempo fa fu defaced la home delle poste... Ora, immaginiamo se le poste ammettessero pubblicamente di usare il framework XXX opensource: si scatenerebbe una corsa tra gli hacker disonesti a cercare le vulnerabilità, e poichè il software perfetto non può esistere queste sarebbero facilmente trovate e sfruttate... o no? Io mi sono sempre interrogato su questo punto.
Lessi sul tutorial di PHP (a proposito dell'estensione .php per questi script) "Security by obscurity is not such a good idea": un software vulnerabile resta vulnerabile pure se non si conosce il sorgente, ma a quel punto trovare le falle diventa molto più difficile, se non impossibile.
Offtopic: Spesso saltano fuori bug critici di kernel, Firefox, Flash... Ma che voi sappiate è mai esistito qualche baco sfruttato??? Perchè tutti rilasciano queste patch ma io non riesco a documentarmi sulle incursioni effettuate con successo. E' una ricerca che ho iniziato tanto tempo fa, ai tempi di "non usare l'account root". Se qualcuno ha dei link interessanti gliene sarei grato

Cioè pensi che sia più facile trovare un bug leggendo righe e righe di codice piuttosto che attaccare un processo in esecuzione?
rock

[phobos3576]

Sono in due ad aver allarmato il mondo Linux kernel!

Ed il Linux security program Grsecurity ha una certa fama.

Tempo fa avevo letto una discussione in proposito tra kernel hackers e, tra essi, Linus Torvalds si era mostrato parecchio seccato definendo esagerato il termine vulnerabilità; in effetti, proprio come dice raffaele181188, si sente continuamente parlare di queste "gravi falle" che però nessuno riesce a sfruttare.

Comunque, precauzionalmente, già da parecchi mesi sto usando mmap_min_addr=4096.

[Mario Vanoni]

Sono in due ad aver allarmato il mondo Linux kernel!

Ed il Linux security program Grsecurity ha una certa fama.

Tempo fa avevo letto una discussione in proposito tra kernel hackers e, tra essi, Linus Torvalds si era mostrato parecchio seccato definendo esagerato il termine vulnerabilità; in effetti, proprio come dice raffaele181188, si sente continuamente parlare di queste "gravi falle" che però nessuno riesce a sfruttare.

Comunque, precauzionalmente, già da parecchi mesi sto usando mmap_min_addr=4096.

Dall'articolo citato:
... discovered that there was a possible null pointer error that could, in theory, enable non-root users grab administrator privileges.

Esagerato forse, ma prevedendo gente capace e pronta a sfruttare la lacuna,
preferisco premunirmi, se 4096 o 65536 al posto di 0 serve ...

No chance ai male intenzionati, Linux non e` il mondo M$,
il codice sorgente e` aperto, se si trova una debolezza,
si allarma il mondo, prima che lo scoprano i cracker!

[raffaele181188]

No, non penso niente ecco perchè chiedevo lumi
Non ho idea di come si possa trovare una vulnerabilità in un processo in esecuzione. Se qualcuno mi ordinasse di trovare un bug nel kernel io non saprei da dove partire. Credo che inizierei a leggere il codice, sì... Ma è proprio per sapere se esistono altre vie che ho postato

[d4z_c0nf]

No, non penso niente ecco perchè chiedevo lumi
Non ho idea di come si possa trovare una vulnerabilità in un processo in esecuzione. Se qualcuno mi ordinasse di trovare un bug nel kernel io non saprei da dove partire. Credo che inizierei a leggere il codice, sì... Ma è proprio per sapere se esistono altre vie che ho postato

Ah ok scusa. Pensavo che stessi dicendo quello.
Non ho esperienze di questo tipo.
Ma ad esempio, se faccio un programma, lo testo per trovare i bug, capito che intendevo?!
rock

[raffaele181188]

Beh sì questo sì, però vedi... Tu che conosci il codice sai "a fiuto", per così dire, quali possono essere i punti deboli. Chi non ha idea si trova più in difficoltà. Ora io non so se, per esempio, con un debugger è sempre possibile risalire a tutto lo stack trace. Tu sai che c'è il patch tuesday per Windows: lì che il codice non è noto come si trovano le vulnerabilità?? Certo, magari tu, per caso, puoi incappare in una funziona bacata dell'API di Win32, alchè segnali la cosa e i developer si mettono all'opera e vedono cosa c'è che non va. Ma loro hanno accesso al codice, tu no! Anche il bug di cui si parla qui.. In fondo si tratta di un valore non valido per quella variabile: ma senza sapere nè che esiste quella variabile, nè chi e come la usa, come si può scoprire una cosa del genere??? La mia ricerca continua... È per questo, comunque, che mi chiedevo se davvero aprire il sorgente può essere una cosa buona per la sicurezza

Offtopic: Ovviamente non voglio crackare niente, ma sapere come avvengono gli exploit è un modo per migliorare il proprio codice

[Mario Vanoni]

Beh sì questo sì, però vedi... Tu che conosci il codice sai "a fiuto", per così dire, quali possono essere i punti deboli. Chi non ha idea si trova più in difficoltà. Ora io non so se, per esempio, con un debugger è sempre possibile risalire a tutto lo stack trace. Tu sai che c'è il patch tuesday per Windows: lì che il codice non è noto come si trovano le vulnerabilità?? Certo, magari tu, per caso, puoi incappare in una funziona bacata dell'API di Win32, alchè segnali la cosa e i developer si mettono all'opera e vedono cosa c'è che non va. Ma loro hanno accesso al codice, tu no! Anche il bug di cui si parla qui.. In fondo si tratta di un valore non valido per quella variabile: ma senza sapere nè che esiste quella variabile, nè chi e come la usa, come si può scoprire una cosa del genere??? La mia ricerca continua... È per questo, comunque, che mi chiedevo se davvero aprire il sorgente può essere una cosa buona per la sicurezza

Offtopic: Ovviamente non voglio crackare niente, ma sapere come avvengono gli exploit è un modo per migliorare il proprio codice

Raffaele
se una debolezza del kernel Linux viene notata,
mettono un workaround subito, no chance ai malintenzionati.

Nell'altro mondo si tengono le debolezze segrete,
ma essendo il mondo utente ad oltre il 95% loro,
come per Linux basta cambiare un numero in un file /proc,
anche li non sara` molto diverso.
I cracker esperimentano, trovata la cifra giusta,
provano ed inventano un virus, una malware ecc.

Quale soluzione preferisci, aperta o closed?

[raffaele181188]

Ma io vorrei sapere da gente navigata in C/programmazione di sistema come è possibile scoprire le vulnerabilità di un programma (compilato evidentemente senza i simboli di debug) senza conoscere assolutamente NIENTE se non l'API pubblica
In via del tutto teorica quando viene fuori una falla nella sicurezza tutte le macchine che non patchano immediatamente sono potenzialmente a rischio. Quindi un attaccante, mettiamo, si fa l'abbonamento a tutti i feed dei blog degli hacker del kernel e, appena viene fuori una vulnerabilità, modifica un qualche programma di uso comune e lo mette in giro. In un programma closed le vulnerabilità vengono per lo più scoperte dai tester stessi (credo) che ovviamente nè le dichiarano nè le sfruttano! A naso mi pare un sistema più sicuro, ma siccome è meglio affidarsi al cervello che non al naso io chiedo qui.
Da un codice macchina si può risalire al linguaggio di alto livello, ma penso che in casi di software closed si perdano i commenti e i nomi dei simboli, giusto? Sfruttando solo il codice disassemblato e l'API pubblica come trovereste voi una vulnerabilità??? Senza poter leggere il sorgente, dico.. Che poi, anche a voler leggere il sorgente, ci vorrebbe una vita per leggere e capire il sorgente di Linux, figuriamoci di Windows. E poi sul fare le mille prove.. Insomma, non mi sembra questa la strada che un cracker può percorrere

[Toni]

Ma io vorrei sapere da gente navigata in C/programmazione di sistema come è possibile scoprire le vulnerabilità di un programma (compilato evidentemente senza i simboli di debug) senza conoscere assolutamente NIENTE se non l'API pubblica

Dal codice macchina .

Tanto per rendere l'idea , in giro c'è gente ,che dando uno sguardo al codice macchina , capisce con quale compilatore è stato compilato

In un programma closed le vulnerabilità vengono per lo più scoperte dai tester stessi (credo) che ovviamente nè le dichiarano nè le sfruttano! A naso mi pare un sistema più sicuro, ma siccome è meglio affidarsi al cervello che non al naso io chiedo qui.

Sistema più sicuro ??????

Talmente sicuro da necessitare un sistema antivirus

Ti invito a documentarti un po perche hai le idee poco chiare

UPDATE:

scusa se non ti dò ulteriori chiarimenti ma l'argomento è troppo vasto ed al momento il tempo è tiranno

[RedSkull92]

per non parlare dei fix, rilasciati dopo MESI E MESI, (esempio IE) mentre se su firefox viene scoperta una vulnerabilità dopo pochi giorni viene rilasciato un update che corregge la falla...

[luka64]

Approfitto di questo thread per porre ai Sysadmins qualche domanda
di aggiornamento personale (che può essere utile a tutti):
-un kernel moderno compilato -Grsec può 'sostanzialmente' essere definito a prova di bomba?
-un buon IDS e gli skills dell'Amministratore possono sostituire degnamente quanto sopra?
ringrazio anticipatamente

[twister]

- In informatica nulla è sicuro a meno che non sia spento, sotto 30 metri di terra dentro una cassaforte.
- In linea di massima si, ma un amministratore non amministra in genere una sola macchina ed è altresì raro avere un ambiente omogeneo, quindi il problema diventa quello di star dietro a tutti i security advisor per tutte le architetture/version/sw installati ecc...

[luka64]

ok, grazie twister, sul punto uno siamo d'accordissimo
noto la grande differenza che c'è rispetto ai tempi che furono,
dovuta anche e soprattutto all'utilizzo del free software: (mi correggo, open source)
vulnerabilità----->patch in tempi ristrettissimi
condivisione files tra diversi sistemi operativi
obbligo quotidiano per l'Amministratore di star dietro ai sec advisories.

[twister]

Beh, mi/ci pagano anche per questo

[slucky]

allora, non ero a conoscenza di questa vulnerabilità del kernel, comunque il comando sul kernel 2.6.31.5 che sto usando mi restituisce il valore 4096, e comunque in ogni caso, a prescindere da ciò, straquoto in pieno le parole di Twister:

In informatica nulla è sicuro a meno che non sia spento, sotto 30 metri di terra dentro una cassaforte.

sante parole....