Shellshock, una vulnerabilità che può mettere in ginocchio il web

Shellshock, una vulnerabilità che può mettere in ginocchio il web

Il bug Shellshock o Bash-bug è una pericolosa vulnerabilità che affligge i sistemi basati su Linux/Unix e che può interessare un numero sterminato di sistemi e dispositivi connessi. Le implicazioni sono anche peggiori rispetto a quanto accadde con Heartbleed

di pubblicato il nel canale Sicurezza
 
40 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
fbf26 Settembre 2014, 16:05 #11
Tanto per cambiare Apple tende a minimizzare i suoi problemi senza poi fornire nessuna spiegazione sul perchè i suoi utenti dovrebbero stare tranquilli.
Questi due articoli:

http://security.stackexchange.com/q...ld-be-exploited

https://www.trustedsec.com/septembe...-proof-concept/

spiegano come basti collegarsi con un sistema vulnerabile ad una rete wi-fi e vedere il proprio file /etc/passwd recapitato al malintenzionato di turno...
s0nnyd3marco26 Settembre 2014, 16:34 #12
Originariamente inviato da: pabloski
Sono i sistemi GNU/Linux, Mac OS X e BSD ad essere vulnerabili.


FreeBSD ha come shell di default tcsh, NetBSD e OpenBSD ksh. Le distro linux basate su debian hanno uno softlink tra /bin/sh (la shell che andrebbe usata negli script) e dash (non la bash).
pabloski26 Settembre 2014, 16:42 #13
Originariamente inviato da: coschizza
curioso allora mi spieghi perche se lancio la stringa:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

sul mio cellulare mi da "vulnerable"?
Inoltre se non ha Bash perche mi si apre la shell dei comandi?

E uso cyanomod che è molto piu android pulito di molte rom standard come quelle samsung che a parita di installazione mi occupa 1,2+ GB di spazio per app inutili.


Leggi qua http://attivissimo.blogspot.it/2014...t=1411621091733

"Grazie della info. Lo ho provato anche con il mio cellulare aggiornato ad Android 4.4.4 (Cyanogenmod) e ne è affetto."

Io ho provato su un nexus s, un pad zenithink e uno onda, 2 minipc con rk3188 e il bug non c'è, o meglio è bash a non esserci.

Mi spiace, cyanogenmod è tra le poche rom android ad usare bash.

Originariamente inviato da: s0nnyd3marco
FreeBSD ha come shell di default tcsh, NetBSD e OpenBSD ksh. Le distro linux basate su debian hanno uno softlink tra /bin/sh (la shell che andrebbe usata negli script) e dash (non la bash).


Purtroppo c'è la brutta abitudine di settare bash come shell di default. Si salvano coloro che restano fedeli alle shell di default
Crash Cilea26 Settembre 2014, 16:59 #14
"Un attacco ha anche portato all'apertura/chiusura di un drive CD/DVD di un server"

Provo inquietitudine =)
t0mcat26 Settembre 2014, 17:16 #15
sempre a dare addosso a PHP, ma proprio in sto caso sono più vulnerabili le applicazioni su stack Python o Ruby.

i web server su stack LAMP di default non sono vulnerabili perché la configurazione più diffusa non usa la modalità CGI, quindi le variabili di ambiente non si propagano tramite gli header HTTP, e non vengono passate neanche nelle funzioni di sistema tipo 'system' o 'exec'.
dennyv26 Settembre 2014, 18:17 #16
Notizia sensazionalistica già abbondantemente ridimensionata.

C'è da tenere presente, come già detto in altri commenti, che sono exploitabili da remoto solo sistemi che usano CGI scritti in Bash ed eseguiti da un interprete bash afflitto dal bug (ne sono esclusi quelli in altri linguaggi, C, perl, python...).

E' vero che uno di questi è l'abbastanza diffuso cPanel.

FastCGI e i vari mod_* sono anch'essi esclusi. Per quanto riguarda i dispositivi embedded un po' di allarmismo ci sta, ma la maggior parte sono basati su busybox, quindi non sono vulnerabili (a cominciare da dd-wrt e open-wrt).

Comunque aggiornare bash su un sistema Linux richiede 1 minuto e mezzo, niente riavvii. Se poi uno usa un sistema fuori dal periodo di supporto... beh, deve mettere in conto problemi simili.
koni26 Settembre 2014, 19:22 #17
ma se uno sul mac ci mette un webserver per fare test delle pagine html e php il computer diventa vulnerabile a questo bug ?
maldestr026 Settembre 2014, 20:36 #18
Originariamente inviato da: dennyv
C'è da tenere presente, come già detto in altri commenti, che sono exploitabili da remoto solo sistemi che usano CGI scritti in Bash ed eseguiti da un interprete bash afflitto dal bug (ne sono esclusi quelli in altri linguaggi, C, perl, python...).
Hanno fatto anche vedere che si poteva entrare nel sistema tramite DHCP.
Peccato però che la shell in cui sia entrato il tizio era quella di un utente normale, e non di root.
Quindi a conti fatti, può fare ben poco, senza una vulnerabilità terza che gli possa far scalare i privilegi fino a root. Per come la vedo io, si tratta più di un Proof of Concept che di una vulnerabilità davvero sfruttabile.
eaman26 Settembre 2014, 20:49 #19
Il problema e' una bella rogna, ma si tenga conto che da tempo molti sistemi tra cui sopratutto i tanto citati devices dedicati (ma anche le distro basate su debian) non usano bash ma soluzioni minori come dash come shell di default per gli scripts.
A parte quelli che usano busybox o ambienti ridotti / customizzati.

Che ovviamente non e' sensibile a questo bug.

Description-en: POSIX-compliant shell
The Debian Almquist Shell (dash) is a POSIX-compliant shell derived
from ash.
.
Since it executes scripts faster than bash, and has fewer library
dependencies (making it more robust against software or hardware
failures), it is used as the default system shell on Debian systems.
Zenida26 Settembre 2014, 23:14 #20
Cmq è confermato che per le CM il terminale bash è presente di default... ma alla fine è risolvibile eliminando il problema alla radice

piuttosto... io ho il debug USB sempre abilitato... in qualche modo è possibile exploitare questo protocollo per inviare comandi dalla rete piuttosto che da USB?

tra l'altro tra le opzioni sviluppatore è possibile impostare ADB anche tramite rete... quindi in un qualche modo le CM sono vulnerabili se tale impostazione è abilitata.

e basterebbe disabilitare la funzionalità ad evitare un potenziale attacco?

Io per sicurezza ho disabilitato il debug USB e impostato l'accesso Root solo alle app ma non ad ADB
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^