Linux.Darlloz è un worm che attacca i router

[Piccioneviaggiatore]

Cosa c'entra tutto cio' con il firmware di un modem/router?
per l voro mi occupo di queste problematiche e se si parla di sicurezza di un SISTEMA OPERATIVO non consiglierei Win nenache al mio piu' feroce e antipatico nemico!.
Conosci per caso un router che abbia un firmware basato su windows?
A memoria non ne conosco.
Qui non si parla di impenetrabilita' ma di sicurezza....
Se vuoi qualcosa i decente,come sistema operativo,usa BSD...ma...cristo...windows proprio NO !!!!

[WarDuck]

Originariamente inviato da s0nnyd3marco

La frammentazione di linux e' sfavorevole ai malware per il fatto che non puoi dare per scontato di poter sfruttare un certo exploit su una macchina (chissa' che versione del kernel, che librerie, che configurazione, se compilata con che use flag ecc).

Non puoi mischiare le carte, devi dire a che livello ti metti.

Se la vuoi vedere al livello kernel, allora saranno colpite tutte le distribuzioni che hanno la specifica versione del kernel con gli appositi flag compilati (es. se voglio attaccare Ubuntu 12.04LTS so per certo che la maggioranza di queste distribuzioni avrà kernel 3.2, così come Debian 7, volendo posso anche andarmi a leggere il config per vedere quali sono i flags di default).

Se la vuoi vedere a livello applicativo allora già non ti interessa più la frammentazione di Linux (in quanto kernel), ma saranno interessati tutti i sistemi che hanno quella specifica versione dell'applicativo.

Se la vuoi vedere a livello di librerie allora saranno colpite tutte le distribuzioni e le applicazioni che ci girano sopra che usano quella specifica versione di libreria.

Ovviamente ci può anche essere una dipendenza incrociata per generare una falla, questo si, ma questo può prescindere dal sistema.

Inoltre da questo punto di vista si può ribaltare la frittata e dire che gli aggiornamenti di sicurezza potrebbero non essere distribuiti nello stesso momento tra tutte le piattaforme, come invece avviene su Windows.

E' chiaro che ogni cosa ha i suoi pregi ed i suoi difetti.

Originariamente inviato da s0nnyd3marco

La parte in assembly spiegala, perche' non vedo cosa ha a che fare con il discorso delle librerie.

Era per dire, anche perché in realtà non è neanche più necessario: si possono creare eseguibili standalone C senza dipendere da alcuna libreria esterna.

Comunque il succo del discorso è che bisogna vedere di che tipo di falla stiamo parlando.

Ogni falla fa storia a se.

[WarDuck]

Originariamente inviato da Piccioneviaggiatore

Cosa c'entra tutto cio' con il firmware di un modem/router?
per l voro mi occupo di queste problematiche e se si parla di sicurezza di un SISTEMA OPERATIVO non consiglierei Win nenache al mio piu' feroce e antipatico nemico!.

Puoi consigliare quello che vuoi a chiunque tu voglia.

Basta che siamo d'accordo che la sicurezza del sistema operativo è una cosa mentre la sicurezza delle applicazioni un'altra cosa.

Altrimenti non si sta capendo di cosa si parla.

Originariamente inviato da Piccioneviaggiatore

Conosci per caso un router che abbia un firmware basato su windows?
A memoria non ne conosco.
Qui non si parla di impenetrabilita' ma di sicurezza....
Se vuoi qualcosa i decente,come sistema operativo,usa BSD...ma...cristo...windows proprio NO !!!!

L'utilizzo di Linux è dovuto principalmente ad un discorso di modularità/apertura e personalizzazione. Se Windows avesse queste caratteristiche (e non le ha semplicemente perché è pensato per tutt'altro), nessuno lo vieterebbe in teoria.

Hanno messo il kernel di Windows 8 su un cellulare (WP8 di fatto), quindi tecnicamente lo possono mettere tranquillamente su un router.

Il discorso di sicurezza nel caso dei router è affidato interamente al produttore del router, inoltre bisogna vedere con quali modalità vengono rilasciati eventuali aggiornamenti.

Se l'aggiornamento è a carico del cliente, allora possiamo stare freschi, e non mi venissero a parlare di sicurezza.

La maggior parte dei report annuali di sicurezza dimostra che se tutti aggiornassero i propri sistemi (mac, linux o windows che sia) la maggioranza delle falle non avrebbero effetti.

La verità è che c'è chi non aggiorna, anche per scelta, specie quei sysadmin che per paura di sputtanare tutto NON aggiornano (e succede anche in ambiente Linux purtroppo).

[s0nnyd3marco]

Originariamente inviato da WarDuck

Non puoi mischiare le carte, devi dire a che livello ti metti.

Se la vuoi vedere al livello kernel, allora saranno colpite tutte le distribuzioni che hanno la specifica versione del kernel con gli appositi flag compilati (es. se voglio attaccare Ubuntu 12.04LTS so per certo che la maggioranza di queste distribuzioni avrà kernel 3.2, così come Debian 7, volendo posso anche andarmi a leggere il config per vedere quali sono i flags di default).

Se la vuoi vedere a livello applicativo allora già non ti interessa più la frammentazione di Linux (in quanto kernel), ma saranno interessati tutti i sistemi che hanno quella specifica versione dell'applicativo.

Se la vuoi vedere a livello di librerie allora saranno colpite tutte le distribuzioni e le applicazioni che ci girano sopra che usano quella specifica versione di libreria.

Ovviamente ci può anche essere una dipendenza incrociata per generare una falla, questo si, ma questo può prescindere dal sistema.

Inoltre da questo punto di vista si può ribaltare la frittata e dire che gli aggiornamenti di sicurezza potrebbero non essere distribuiti nello stesso momento tra tutte le piattaforme, come invece avviene su Windows.

E' chiaro che ogni cosa ha i suoi pregi ed i suoi difetti.

La maggior parte delle distribuzioni principali, quando esce una nuova vulnerabilita', fanno uscire piu' o meno tutte una patch nello stesso periodo. Le altre seguono a ruota. Chiaro che se guardi linux pinco pallo mantenuto da due ragazzetti chissa' quando e se patchano.

Le tue considerazioni sono tutte valide e le condivido; ma la frammentazione di linux (inteso come gnu linux e non solo il kernel) sta anche nelle librerie e nei applicativi (non e' che tutti le distro hanno la stessa versione di libre office, magari i mantainer la hanno patchata con qualcosa di non ufficiale ecc).

Ovviamente sono consapevole che la frammentazione non e' una reale sicurezza, ma solo un disincentivo ai malware writer.

Originariamente inviato da WarDuck

Era per dire, anche perché in realtà non è neanche più necessario: si possono creare eseguibili standalone C senza dipendere da alcuna libreria esterna.

Comunque il succo del discorso è che bisogna vedere di che tipo di falla stiamo parlando.

Ogni falla fa storia a se.

Sarei curioso di sapere se c'e' una classifica sull'uso dei linguaggi nella scrittura dei malware.

[LMCH]

Originariamente inviato da WarDuck

Quando un malware attacca Java/Flash/Adobe e vulnerabilità varie degli applicativi Windows si da la colpa al sistema operativo Windows.

Se la cosa dipende dall'applicazione si da la colpa all'applicazione, ma molta confusione in proposito è stata causata da Microsoft stessa quando durante la causa Antitrust riguardo i web browser ha dichiarato che IE era "parte integrante del sistema operativo".

IE per anni ha avuto un fottio di problemi a causa della sua architettura COM-based che lo rendeva estremamente vulnerabile ad attacchi.

In poche parole: chi è causa del suo mal pianga se stesso.

[Piccioneviaggiatore]

@antonio23
Vedo che le domande retoriche sono il tuo forte.
E per fortuna che la mamma ti giudica intelligente.

[eraser]

Originariamente inviato da s0nnyd3marco

Sarei curioso di sapere se c'e' una classifica sull'uso dei linguaggi nella scrittura dei malware.

Dipende dalla categoria di malware. Se intendi i classici virus/worm/trojan/backdoor/rootkit sicuramente il C/C++ e il delphi sono tra i più diffusi (con diverse righe di Assembly per quanto riguarda alcuni rootkit specifici). Per infezioni più basilari vengono tranquillamente utilizzati - seppure con minore frequenza - anche linguaggi quali .NET, RealBasic e il Visual Basic

[pabloski]

Originariamente inviato da LMCH

IE per anni ha avuto un fottio di problemi a causa della sua architettura COM-based che lo rendeva estremamente vulnerabile ad attacchi.

Hai fatto bene a citare COM. Quello che diceva Warduck è in parte vero, ma va valutato caso per caso.

Quando una vulnerabilità riesce ad eseguire codice remoto, la colpa può essere del singolo software, del sistema operativo o di entrambi. Un OS che non implementa tecniche per evitare l'esecuzione di codice dallo stack, è sicuramente corresponsabile.

MS ha prodotto, per anni, software scadente, a partire dal sistema operativo, cominciando con un OS ( xp ) in cui l'utente di default è amministratore. Insomma, hanno dimostrato di non conoscere ( o non voler implementare ) nemmeno l'abc delle misure di sicurezza, arcinote nell'ambiente da decenni.

Per cui la pessima reputazione se la sono meritata. C'è poco da piagnucolare e gridare al "gombloddo".

[barzokk]

Originariamente inviato da pabloski

Insomma, hanno dimostrato di non conoscere ( o non voler implementare ) nemmeno l'abc delle misure di sicurezza, arcinote nell'ambiente da decenni.

lo sappiamo tutti che hanno sempre ignorato i problemi di sicurezza perchè per loro non era strategico
d'altra parte l'utonto vuole solo qualcosa che clicchi next-next-next e fa tutto da solo
si sono mossi (un pochino) solo quando hanno iniziato a perdere clienti

Originariamente inviato da pabloski

Per cui la pessima reputazione se la sono meritata. C'è poco da piagnucolare e gridare al "gombloddo".

beh, più che meritata, è una feature, la insicurezza è intrinseca del progetto originale windows

[eraser]

Originariamente inviato da pabloski

Hai fatto bene a citare COM. Quello che diceva Warduck è in parte vero, ma va valutato caso per caso.

Quando una vulnerabilità riesce ad eseguire codice remoto, la colpa può essere del singolo software, del sistema operativo o di entrambi. Un OS che non implementa tecniche per evitare l'esecuzione di codice dallo stack, è sicuramente corresponsabile.

MS ha prodotto, per anni, software scadente, a partire dal sistema operativo, cominciando con un OS ( xp ) in cui l'utente di default è amministratore. Insomma, hanno dimostrato di non conoscere ( o non voler implementare ) nemmeno l'abc delle misure di sicurezza, arcinote nell'ambiente da decenni.

Per cui la pessima reputazione se la sono meritata. C'è poco da piagnucolare e gridare al "gombloddo".

Linux ha implementato il supporto per l'NX bit con il kernel 2.6.8 nel 2004. Microsoft in Windows XP con il Service Pack 2 nel 2004.

Windows XP ha strumenti per la sicurezza del sistema operativo efficaci e ben funzionanti, tutto sta a volerli utilizzare.

Per quanto riguarda la responsabilità del sistema operativo nell'intercettare le falle delle applicazioni, allora Linux è responsabile del fatto che il server X non garantisca un corretto isolamento degli utenti nella stessa sessione, semplificando di non poco il lavoro di eventuali keylogger.

Mai mi sognerei di dire ciò, ma se queste cose vanno dette per Windows allora vanno dette anche per Linux

[barzokk]

Originariamente inviato da eraser

Windows XP ha strumenti per la sicurezza del sistema operativo efficaci e ben funzionanti,

seems legit !

[pabloski]

Originariamente inviato da eraser

Linux ha implementato il supporto per l'NX bit con il kernel 2.6.8 nel 2004. Microsoft in Windows XP con il Service Pack 2 nel 2004.

il bit nx è solo una delle possibili modalità per proteggere lo stack

l'uso dei canaries è presente in linux da decenni

Originariamente inviato da eraser

Windows XP ha strumenti per la sicurezza del sistema operativo efficaci e ben funzionanti, tutto sta a volerli utilizzare.

oddio, non avere nemmeno uno straccio di sudo, non è un metodo efficace e ben funzionante

Originariamente inviato da eraser

Per quanto riguarda la responsabilità del sistema operativo nell'intercettare le falle delle applicazioni, allora Linux è responsabile del fatto che il server X non garantisca un corretto isolamento degli utenti nella stessa sessione, semplificando di non poco il lavoro di eventuali keylogger.

non vedo il perchè, nessun altro kernel si occupa di tale situazione

come ho scritto sopra, il kernel/so è responsabile laddove non implementa soluzioni note all'interno della comunità degli sviluppatori di kernel e sistemi operativi

[eraser]

Originariamente inviato da pabloski

il bit nx è solo una delle possibili modalità per proteggere lo stack

l'uso dei canaries è presente in linux da decenni

Hai parlato di Windows. L'uso delle canaries è in fase di compilazione, non di runtime. Le mette GCC con StackGuard, non il kernel. Se bisogna fare i paragoni, vanno fatti alla pari

oddio, non avere nemmeno uno straccio di sudo, non è un metodo efficace e ben funzionante

Il Run As c'è sempre stato, anche se è vero che in Windows XP aveva alcune limitazioni. Cosa corretta con Windows Vista e poi Windows 7

non vedo il perchè, nessun altro kernel si occupa di tale situazione

come ho scritto sopra, il kernel/so è responsabile laddove non implementa soluzioni note all'interno della comunità degli sviluppatori di kernel e sistemi operativi

A partire da Windows Vista viene correttamente effettuato l'isolamento di differenti utenti all'interno della stessa sessione tramite tecnologie quali UIPI, implementato lato kernel.

Linux non ha niente di tutto ciò ad oggi, perché in un sistema Linux ciò non è considerato al momento un suo compito

[pabloski]

Originariamente inviato da eraser

Hai parlato di Windows. L'uso delle canaries è in fase di compilazione, non di runtime. Le mette GCC con StackGuard, non il kernel. Se bisogna fare i paragoni, vanno fatti alla pari

questo è vero....dunque stiamo parlando del solo kernel? lo dico perchè, altrimenti, è difficile capire quali componenti stiamo considerando nell'insieme

Originariamente inviato da eraser

Il Run As c'è sempre stato, anche se è vero che in Windows XP aveva alcune limitazioni. Cosa corretta con Windows Vista e poi Windows 7

era proprio alle limitazioni che mi riferivo

del resto c'erano pure gli account limitati, ma erano/sono inflessibili e minano l'usabilità ( considerando l'utente tipo )

Originariamente inviato da eraser

A partire da Windows Vista viene correttamente effettuato l'isolamento di differenti utenti all'interno della stessa sessione tramite tecnologie quali UIPI, implementato lato kernel.

Linux non ha niente di tutto ciò ad oggi, perché in un sistema Linux ciò non è considerato al momento un suo compito

vale il discorso di gcc

stiamo considerando esattamente quali componenti? linux non implementa metodologie uipi perchè non considera l'interfaccia utente come parte naturale del sistema

una toppa l'ha messa android, ma lì c'è dietro un'implementazione particolare dei meccanismi di sicurezza e un buon uso delle capabilities ( che molti sistemi mainstream nemmeno prendono in considerazione )

[eraser]

Originariamente inviato da pabloski

questo è vero....dunque stiamo parlando del solo kernel? lo dico perchè, altrimenti, è difficile capire quali componenti stiamo considerando nell'insieme

Non so, io sono intervenuto perché ho visto un'affermazione a mio avviso errata che mischiava le carte in tavola

Originariamente inviato da pabloski

Quando una vulnerabilità riesce ad eseguire codice remoto, la colpa può essere del singolo software, del sistema operativo o di entrambi. Un OS che non implementa tecniche per evitare l'esecuzione di codice dallo stack, è sicuramente corresponsabile

Windows ha cominciato ad implementare il supporto NX bit nel 2004, esattamente come Linux con il kernel 2.6.8. Se poi parliamo del supporto allo stack cookie, lì il discorso è differente e non è responsabilità del sistema operativo, ma semmai dei vari compilatori.

Poi il resto non so, non ho seguito completamente la discussione