"Shellshock" mette in crisi la credibilità UNIX?

[spoonriver]

https://gigaom.com/2014/09/25/the-criti ... d-to-know/

Non sono per nulla esperto, ma mi immagino già commenti acidi, risolini e "A-ha" stile Nelson dei Simpson...
A livello più concreto invece: per noi miseri utenti comuni, cambierà qualcosa? è necessario intervenire personalmente o ci penseranno a livello di Distro?

[Mdfalcubo]

Visto che colpisce anche Apple ci penseranno loro presumo.

[Wilson]

Nei repo c'è già (da stanotte) la versione patchata di bash, chi ha impostato gli aggiornamenti di sicurezza in automatico ce l'ha già installata (tipo il mio serverino domestico)

Pare che nel frattempo abbiano scoperto una falla secondaria, la patch c'è già ma deve ancora arrivare nei repo.

In ogni caso Ubuntu (in quando derivata da Debian) è particolarmente poco colpita: di solito gli script non invocano direttamente bash, ma sh (la shell base) che in tutte le distro non è altro che un collegamento a un'altra shell, che può essere Bash come un'altra, da quel che ho capito in Debian e Ubuntu è un link a Dash, che non ha la falla in questione.

ps: la cosa è parecchio grave, pare abbiano già trovato i primi malware che di diffondono grazie a questo problema.

[Wilson]

Uscita anche la seconda patch

[superlex]

Sia su Ubuntu che su Arch mi pare siano già state risolte entrambe le vulnerabilità.
Quello che non ho capito è come (e se) il problema riguardi anche router, smarthphone e in generale sistemi embedded. Lì uno come fa ad aggiornare?

[Wilson]

Sia su Ubuntu che su Arch mi pare siano già state risolte entrambe le vulnerabilità.
Quello che non ho capito è come (e se) il problema riguardi anche router, smarthphone e in generale sistemi embedded. Lì uno come fa ad aggiornare?

Non lo fa e resta vulnerabile (e già ci sono gli exploit facili facili, mi pare di capire).

Non so se ci sia già aggiornamento per i Mac

Android dovrebbe essere privo di Bash e quindi esente dal problema

[sbubba]

uhm leggevo in giro:
"Prova questo nella shell:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
se printa questo dovrebbe essere tutto ok:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test "

su debian ho dato il comando ma non mi riporta gli errori, mi esce solo la scritta "this is a test". presumo che il bugfix non lo abbia ancora installato, sbaglio?

[superlex]

@Wilson
per i router dici? e quindi?
Per i Mac Apple ha dichiarato che rilascerà l'aggiornamento al più presto, alcuni utenti stanno applicando direttamente le patch di gnu.org.

@sbubba
se non esce la scritta "vulnerable" allora sei a posto.
il 2° test invece deve scrivere un file nominato "echo", se non lo scrive non c'è la vulnerabilità.

Codice: Seleziona tutto

env X='() { (a)=>\' sh -c "echo date"; cat echo

[spak]

È un problema serio, sopratutto per i router non più supportati.
Cosa consigliate di fare, buttare il vecchio router e acquistarne uno nuovo; ma poi bisognerebbe trovare un router che sia sempre aggiornabile il firmware.
Esistono router opensource che siano aggiornabili per un lungo periodo, senza backdoors nascoste?

[Vanpivix]

È un problema serio, sopratutto per i router non più supportati.
Cosa consigliate di fare, buttare il vecchio router e acquistarne uno nuovo; ma poi bisognerebbe trovare un router che sia sempre aggiornabile il firmware.
Esistono router opensource che siano aggiornabili per un lungo periodo, senza backdoors nascoste?

c'è un modo per scoprire se il mio router è vulnerabile? Quali sono i rischi?

[maxbigsi]

È un problema serio, sopratutto per i router non più supportati.
Cosa consigliate di fare, buttare il vecchio router e acquistarne uno nuovo; ma poi bisognerebbe trovare un router che sia sempre aggiornabile il firmware.
Esistono router opensource che siano aggiornabili per un lungo periodo, senza backdoors nascoste?

c'è un modo per scoprire se il mio router è vulnerabile? Quali sono i rischi?

anche se qui siamo
http://www.dapinna.com/notizie/30-avvis ... zione.html

http://www.dapinna.com/notizie/30-avvis ... arche.html

[sbubba]

@sbubba
se non esce la scritta "vulnerable" allora sei a posto.
il 2° test invece deve scrivere un file nominato "echo", se non lo scrive non c'è la vulnerabilità.

Codice: Seleziona tutto

env X='() { (a)=>\' sh -c "echo date"; cat echo

su un altro pc sempre con debian:

Codice: Seleziona tutto

 env x='() { :;}; echo vulnerable' bash -c "echo this is a test
> 

praticamente mi apre una shell per scrivere i comandi? o__O

con il 2° che mi hai detto tu mi viene fuori:

Codice: Seleziona tutto

env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: File o directory non esistente

[Actarus5]

@sbubba
se non esce la scritta "vulnerable" allora sei a posto.
il 2° test invece deve scrivere un file nominato "echo", se non lo scrive non c'è la vulnerabilità.

Codice: Seleziona tutto

env X='() { (a)=>\' sh -c "echo date"; cat echo

su un altro pc sempre con debian:

Codice: Seleziona tutto

 env x='() { :;}; echo vulnerable' bash -c "echo this is a test
> 

praticamente mi apre una shell per scrivere i comandi? o__O

con il 2° che mi hai detto tu mi viene fuori:

Codice: Seleziona tutto

env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: File o directory non esistente

Il primo comando è così:

Codice: Seleziona tutto

 env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Avevi dimenticato i doppi apici finali.

Per quanto riguarda il secondo dovresti essere avere la versione patchata, in quanto il file echo non viene creato... Quale versione hai attualmente? ( Puoi vederlo col comando bash --version )

[ale4]

Per i router state tranquilli, solitamente non hanno una shell bash ma usano busybox, un unico binario che oltre a contenere la shell contiene i comandi base unix (ls, cd, ecc), che non è vulnerabile, e anche android non ha bash ma anch'esso busybox, come praticamente tutti i dispositivi embedded...

Al limite i router su cui si è installato openwrt so che hanno bash, però li usciranno le patch quindi c'è da stare tranquilli, poi comunque non è detto che il bug di bash sia sfruttabile dall'esterno, per esempio se sul router avete impostato l'interfaccia di configurazione come accessibile solo dalla lan e non dall'esterno potete stare tranquilli...

Comunque hanno fatto il problema più grave di quello che è alla fine, insomma la vulnerabilità è sfruttabile solo per webserver esposti sulla rete e solo se questi eseguono script cgi in bash, o eseguono script o programmi cgi che richiamano bash in modo poco sicuro, una minima percentuale (mai sentito di chi usa bash come linguaggio di programmazione cgi...)

[sbubba]

@Actarus5: ah sì, hai ragione. dimenticato gli apici :°D mi riporta "this is a test".
appena acceso ho aggiornato e mi ritrovo: GNU bash, version 4.2.37(1)-release (i486-pc-linux-gnu) quindi dovrebbe essere a posto. grazie

[Wilson]

Comunque hanno fatto il problema più grave di quello che è alla fine, insomma la vulnerabilità è sfruttabile solo per webserver esposti sulla rete e solo se questi eseguono script cgi in bash, o eseguono script o programmi cgi che richiamano bash in modo poco sicuro, una minima percentuale (mai sentito di chi usa bash come linguaggio di programmazione cgi...)

Ehm, dhcp-client usa sh (e quindi, su molti sistemi linux, bsd e mac, usa bash, credo non su Ubuntu, visto che sh dovrebbe essere un link a dash), c'è già l'exploit prefatto che esegue codice arbitrario ("echo foo", credo, ma ci vuole poco a mettere quello che vuoi) su qualsiasi pc vulnerabile con wifi acceso e impostato per accedere automaticamente alle reti non protette che arrivi a tiro (in pratica crea una rete con un server dhcp che usa la vulnerabilità).

E anche un sacco di altra roba usa la shell, la gravità sta proprio nel fatto che non è possibile tracciare tutte le potenziali situazioni a rischio.

[kimj]

Wilson, ho trovato questo topic linkato in uno di carattere generale...

se puoi, correggimi se sbaglio ma...
ma NetworkManager non sfrutta dhclient configurato per *non* invocare alcun hook sh?

non sarebbe quindi escluso dal problema? rimarrebbero affetti gli utenti che configurano la rete manualmente con ifupdown per poi usare dhcp, o che invocano manualmente un demone dhcp.
e' certamente grave, ma quanto applicabile nella situazione "internet cafe'"?

spero in ogni caso che questo invogli la comunita' a guardare meglio alla sicurezza ed al sandboxing. in FreeBSD esiste capsicum, e molti componenti sensibili tra cui l'implementazione dhcp sfruttano capsicum per entrare volontariamente in una sandbox che limita anche quali syscall possono eseguire e con che oggetto, a seconda di come ritenuto necessario dallo sviluppatore.
su Linux e' ora disponibile capsicum, ma mi pare non vi sia stato interesse a sfruttarlo per mettere in sicurezza software sensibile; per quanto sia una pessima idea passare input remoto ad una shell, un simile meccanismo renderebbe la vulnerabilita' inutile.

ma ora chiedo: come potrei venire compromesso?
diciamo che ho un mailserver che non posso aggiornare al momento. e' a rischio?

usa dhclient, quindi suppongo di si, ma ho abbastanza fiducia nel provider, anche perche' si tratta di un vps ed il gestore della rete avrebbe modi piu' facili e rapidi di ottenere accesso alle macchine dei clienti.

uso fastcgi al posto di cgi, non ho cgi configurato e non ho da nessuna parte applicazioni cgi, men che meno script bash.
non ho shell accessibili liberamente e spero di essere l'unico utente.

non ho impostato filtri/trasporti/script in postfix (od altri mta: questa non l'ho ancora sentita menzionare, ma basterebbe una email con un oggetto ad hoc ad esempio per compromettere tutte le machine da cui passa. il che sa tanto della famosa email dell'nsa che, pian piano che passava da ogni relay anonimo, comunicava I loro indirizzi ip - da digital fortress, per quanto inaccurato)

come sarei affetto da 'shellshock'?

[kimj]

la fonte dovrebbe essere questo bug: https://bugs.launchpad.net/ubuntu/+sour ... bug/293139

dove e' anche menzionata la possibilita' di usare /etc/networkmanager/dispatcher.d per eseguire script. ma diventa di nuovo un caso non cosi' tanto generale da compromettere tutti gli unix da remoto secondo volere di chuck Norris...

non posso verificare essendo sprovvisto di un pc con Linux al momento.
inoltre, se hai tempo e non ti secca o ritieni sia meglio non interloquire con me vista l'esperienza passata, puoi verificare se esiste un profilo apparmor per I client dhcp, se e' abilitato e se serve veramente a qualcosa? (a differenza di quello firefox...)

[kimj]

strano poi che nessuno ancora abbia scritto che in alcuni diffusi casi, certamente piu' diffusi di script cgi fatti in bash, sia possibile con questa vulnerabilita' compromettere server inviando una email con oggetto ad-hoc... il che fa tanto '90.

probabilmente perche' sino ad ora hanno scritto a riguardo molti 'ricercatori di sicurezza', giornalisti che vanno a caccia di criminali informatici, wired e tutto quanto, ma non chi gestisce le macchine...

[Wilson]

Credo di poterti rispondere solo "non lo so".

Posso dire che i sistemi derivati da Debian sono meno a rischio, perché usano dash e non bash come sostituto di sh (e di solito gli script invocano sh). Non so se sia una scelta di sicurezza o altro, non conosco né le differenze né il processo che ha portato a questa scelta, posso solo dire che il rimpiazzo di sh dovrebbe essere il più semplice possibile, visto l'uso ubiquo degli script in un sistema Unix (in questo i fan di win non hanno torto: non è molto elegante avere un groppo di script tra i componenti essenziali di sistema, come l'avvio).
Non so quanto sandbox e simili possano essere risolutivi, se da una parte aggiungono uno strato di difesa, dall'altra aggiungono pure un elemento in più che potrebbe contenere un errore, onestamente sono contento del fatto che porsi queste domande non sia compito mio.

Non sono sicuro di cosa intendi per "situazione internet cafè", ma è sicuramente possibile se si accede (o meglio ancora si gestisce) a una rete locale mettere su un rogue dhcp server che prova a sfruttare la vulnerabilità, ho intravisto articoli che descrivevano semplici proof of concept funzionanti (su vittime vulnerabili, credo l'abbiano provato sopratutto sui Mac). Per i motivi detti prima credo che su Debian e derivate non funzioni (e comunque la patch è già in tutti i repo).

Per quel che riguarda il mailserver non ne ho idea: come al solito posso solo suggerire di cercare online "shellshock + $nomedel server" e vedere se qualcuno ne parla. Onestamente non mi immagino come un server esposto a internet possa essere non aggiornabile: aggiornare bash non richiede neppure il riavvio, ma gli scenari reali sfuggono sempre alla mia immaginazione (e sono mezzo addormentato).

Di sicuro ci sono o ci saranno molto presto i bot che fanno la pesca a strascico a cercare i sistemi vulnerabili, come ci sono quelli che provano a loggarsi in ssh con user e passwd root o a cercare le pagine di config dei CMS.

All'ultima domanda (come sarei affetto?) posso solo rispondere un grosso "non ne ho idea" e da quel che ho letto in questi giorni il problema di questo coso è proprio che nessuno ne ha idea (io men che meno, comunque): gli script shell sono molto popolari in *unix, qualsiasi programma potrebbe farne uso per qualche motivo e la cosa potrebbe non essere neppure documentata. Ci sono un sacco di consigli su come aggirare il problema bloccano l'accesso a bash o sostituendola con un altra shell, ma tutti finiscono con l'avviso "questo potrebbe scassare qualcosa".

ps: per chi chiedeva come regolarsi col router la risposta è semplice e al contempo fastidiosa: dai per scontato che sia compromesso, configura i vari dispositivi come se sapessi di avere un nemico nella rete interna (e ognuno considerando potenzialmente ostili gli altri), avresti dovuto farlo anche prima quindi non cambia nulla.

pps: un profilo per dhcp client in ubuntu 14.04 c'è (ce ne sono due, per la verità), sulla qualità non mi so esprimere (però ho notato che il nuovo profilo di firefox è migliore del precedente, evidentemente c'è qualcuno che ci lavora). Non so se è abilitato di default perché io ho abilitato tutta la cartella.