Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/shellshock-un-bug-peggiore-di-heartbleed_54207.html

Red Hat scopre un bug che affligge la shell Bash e potrebbe interessare un numero sterminato di sistemi e dispositivi connessi

Click sul link per visualizzare la notizia.

chissà quanto ci avrà mangiato sopra l'nsa con questo bug

per risolverlo basta disabilitare la bash ?

chissà quanto ci avrà mangiato sopra l'nsa con questo bug

per risolverlo basta disabilitare la bash ?

Eh già è la Nsa l'unico pericolo in rete..... virus, mandare, hacker, stalker sono marginali.... :rolleyes:

Eh già è la Nsa l'unico pericolo in rete..... virus, mandare, hacker, stalker sono marginali.... :rolleyes:

sono gli ammmericccannni che ti rubano i soldi e ti invadono :D:D:D

cmq lanciato prima un upgrade con apt-get e mi ha aggiornato la bash con questo aggiornamento sono apposto ?
io ho ubuntu 14

sono gli ammmericccannni che ti rubano i soldi e ti invadono :D:D:D

cmq lanciato prima un upgrade con apt-get e mi ha aggiornato la bash con questo aggiornamento sono apposto ?
io ho ubuntu 14

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

chissà quanto ci avrà mangiato sopra l'nsa con questo bug
Stai attento: la prossima volta che ti bussano alla porta, potrebbe essere LORO :doh::doh:

Ah già, LORO non bussano :cool::cool:

appena aggiornato ubuntu 14.04
il comando mi restituisce quello che hai scritto, grazie per l'info ;)

La patch rilasciata corregge solo parzialmente il problema, il comando
env X='() { (a)=>\' sh -c "echo date"; cat echo
infatti scrive comunque un file.

@r1348

ok, aspettiamo la patch definitiva
...quello che mi preoccupa di più è però il discorso che leggevo su router
o altri dispositivi che potrebbero essere bacati, e con l'impossibilità
di ricevere aggiornamenti (perchè magari vecchi o non più supportati)

sì questo è decisamente TERRIBILE.

l'unica soluzione e' una vita senza connessioni

l'unica soluzione e' una vita senza connessioni

In passato forse http://www.techspot.com/news/41643-intels-sandy-bridge-processors-have-a-remote-kill-switch.html

sono gli ammmericccannni che ti rubano i soldi e ti invadono :D:D:D
[..]
Veramente i più attivi li trovi in Asia ed Europa dell'est.. sai, negli USA son un tantinello più attenti quando si parla di frodi digitali et simila. :rolleyes:


CIAWA

è già uscito l'update che tappa la falla credo... poco fa il mio raspberry pi mi ha segnalato un'aggiornamento per la shell bash che ovviamente ho installato :)

La patch rilasciata corregge solo parzialmente il problema, il comando
env X='() { (a)=>\' sh -c "echo date"; cat echo
infatti scrive comunque un file.


user@ubuntu:~$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory


c'e' ancora il bug ?

per risolverlo basta disabilitare la bash ?
Tanto vale che spegni il pc :fagiano:

Tanto vale che spegni il pc :fagiano:
:asd:


CIAWA

Aggiornato
Debian da security.debian.org aggiorna bash a 4.2+dfsg-0.1+deb7u1

i test ora falliscono entrambi
ivy-srv03:~# /bin/bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
....
ivy-srv03:~# env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
ivy-srv03:~# env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: File o directory non esistente




ArchLinux aggiorna bash a 4.3.024
fallisce il primo test ma il secondo continua a passare
[sandro@XaBook ~]$ /bin/bash --version
GNU bash, versione 4.3.24(1)-release (x86_64-unknown-linux-gnu)
....
[sandro@XaBook ~]$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: attenzione: x: ignoring function definition attempt
bash: errore nell'importazione della definizione di funzione per "x"
hello
[sandro@XaBook ~]$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: riga 1: errore di sintassi vicino al token non atteso "="
sh: X: riga 1: `'
sh: errore nell'importazione della definizione di funzione per "X"
gio 25 set 2014, 13.11.10, CEST

https://bugs.archlinux.org/task/42112?project=1&cat%5B0%5D=31&string=bash

l'unica soluzione e' una vita senza connessioni

allora aspetto il prossimo aggiornamento di iOS e sono a posto :asd:

Mavericks 10.9.5 è vulnerabile ho appena controllato

Ma a questo bug non sono vulnerabili anche i sistemi android? La shell ha molte carattristiche in comune con quella linux, poi non so perchè non sono espertissimo su queste cose

Provato ora su due server dopo update:

CentOs 6.5, parzialmente patchato
Debian 6.0.10, totalmente vulnerabile

Ma a questo bug non sono vulnerabili anche i sistemi android? La shell ha molte carattristiche in comune con quella linux, poi non so perchè non sono espertissimo su queste cose

Android non usa la shell bash, e comunque difficilmente si usa il terminale su android

Provato ora su due server dopo update:

Debian 6.0.10, totalmente vulnerabile

Hai provato ad includere i repo deb security.debian.org oldstable/updates main contrib non-free

Provato ora su due server dopo update:

CentOs 6.5, parzialmente patchato
Debian 6.0.10, totalmente vulnerabile



Android non usa la shell bash, e comunque difficilmente si usa il terminale su android

Hai i repo LTS di Squeeze?

https://wiki.debian.org/LTS/Using

Hai i repo LTS di Squeeze?

Mancavano, che svista...

grazie per la dritta

Mancavano, che svista...

grazie per la dritta

You are welcome!

Aggiornato
Debian da security.debian.org aggiorna bash a 4.2+dfsg-0.1+deb7u1

i test ora falliscono entrambi
ivy-srv03:~# /bin/bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
....
ivy-srv03:~# env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
ivy-srv03:~# env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: File o directory non esistente




su debian sh punta a /bin/dash


$ env X='() { (a)=>\' bash -c "echo date"; cat echo
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
gio 25 set 2014, 18.26.06, CEST

Un altro aspetto che fa riflettere è che questo bug a quanto pare è presente fin da bash 1.13, quindi più di 20 anni.

ma pensa tu.....

Credo che tra Heartbleed e ora sta altra porcata sia il caso di fare un ragionamento sull'Open Source: è codice scritto coi piedi? E' il linguaggio C che non dovrebbe più essere usato (è unsafe by design)? Forse bisognerebbe smetterla di fare i fighi a tutti i costi (perché OpenSSL ha dovuto farsi le proprie versioni di malloc/free? Perché una shell dovrebbe avere funzioni dentro variabili d'ambiente? A che serve :confused: ?) ?

Chissà quanti altri bachi di sicurezza dentro tutti gli applicativi GNU ci saranno a sto punto... la situazione è preoccupante :cry:

Credo che tra Heartbleed e ora sta altra porcata sia il caso di fare un ragionamento sull'Open Source: è codice scritto coi piedi?


Per esperienza ( da quello che ho notato negli ultimi anni ) è l'intero settore IT ad essere crollato in quanto a qualità. Un altro utente ( non ricordo se qui o su tomshw ) faceva notare come la qualità dei display lcd è ormai ai minimi storici, roba che negli anni '90 non avrebbe passato il controllo qualità oggi viene venduta spensieratamente.

Lo stesso discorso si può fare pari pari per il software ( altrimenti non si spiega come abbia fatto Apple a tirar fuori iOS 8.0.1 e brickare migliaia di iphone ).


E' il linguaggio C che non dovrebbe più essere usato (è unsafe by design)?


Questo è un discorso che viene fatto spessissimo anche dai guru, tant'è che la volontà di liquidare C ( e soprattutto C++ ) ha fatto nascere Java, C#, ecc... e più recentemente Go e Rust. Risultato? C e C++ sono sempre lì e sempre più forti.

Chiaramente non offrono tutto ciò che al programmatore moderno ( o distratto!?! ) sembra necessitare. I risultati sono sotto gli occhi di tutti.


Forse bisognerebbe smetterla di fare i fighi a tutti i costi (perché OpenSSL ha dovuto farsi le proprie versioni di malloc/free? Perché una shell dovrebbe avere funzioni dentro variabili d'ambiente? A che serve :confused: ?) ?


Ci sono ragioni tecniche ovviamente, ma non così prioritarie come si può pensare ( almeno per openssl, per bash è un altro discorso ).

Alcune male lingue dicono che una certa agenzia a tre lettere spinga perchè le cose vadano in un certo modo....chissà :D


Chissà quanti altri bachi di sicurezza dentro tutti gli applicativi GNU ci saranno a sto punto... la situazione è preoccupante :cry:

L'unica certezza è che ce ne sono altrettanti nel software closed, con l'aggravante che è più difficile scovarli.

Il problema non è l'open, è l'ingegneria del software che ormai ha perso la bussola ( gli hacker che spaccavano il bit non ci sono più e nemmeno avrebbero tempo per spaccare i loro bit, viste le assurde deadline che vengono imposte oggi ).

Credo che tra Heartbleed e ora sta altra porcata sia il caso di fare un ragionamento sull'Open Source: è codice scritto coi piedi? E' il linguaggio C che non dovrebbe più essere usato (è unsafe by design)? Forse bisognerebbe smetterla di fare i fighi a tutti i costi (perché OpenSSL ha dovuto farsi le proprie versioni di malloc/free? Perché una shell dovrebbe avere funzioni dentro variabili d'ambiente? A che serve :confused: ?) ?

Chissà quanti altri bachi di sicurezza dentro tutti gli applicativi GNU ci saranno a sto punto... la situazione è preoccupante :cry:

I bachi sono ovunque:

http://fc05.deviantart.net/fs71/i/2010/133/9/9/hardware_bug_by_toca_discos.jpg

Mageia 4 patchata ieri, entrambi i test falliscono:


[sandro@localhost bin]$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

[sandro@localhost bin]$ /bin/bash --version
GNU bash, version 4.2.48(2)-release (x86_64-mageia-linux-gnu)

[sandro@localhost bin]$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu Sep 25 22:01:00 CEST 2014

Dovrò dare assolutamente qualche euro in bitcoin ai ragazzi di mageia:

mageia 1GYF2h69NrJ7Pp92bNPDEdLABbH1hR7rsA

patch definitiva arrivata anche nei repo debian :)

Per esperienza ( da quello che ho notato negli ultimi anni ) è l'intero settore IT ad essere crollato in quanto a qualità. Un altro utente ( non ricordo se qui o su tomshw ) faceva notare come la qualità dei display lcd è ormai ai minimi storici, roba che negli anni '90 non avrebbe passato il controllo qualità oggi viene venduta spensieratamente.

Lo stesso discorso si può fare pari pari per il software ( altrimenti non si spiega come abbia fatto Apple a tirar fuori iOS 8.0.1 e brickare migliaia di iphone ).



Questo è un discorso che viene fatto spessissimo anche dai guru, tant'è che la volontà di liquidare C ( e soprattutto C++ ) ha fatto nascere Java, C#, ecc... e più recentemente Go e Rust. Risultato? C e C++ sono sempre lì e sempre più forti.

Chiaramente non offrono tutto ciò che al programmatore moderno ( o distratto!?! ) sembra necessitare. I risultati sono sotto gli occhi di tutti.



Ci sono ragioni tecniche ovviamente, ma non così prioritarie come si può pensare ( almeno per openssl, per bash è un altro discorso ).

Alcune male lingue dicono che una certa agenzia a tre lettere spinga perchè le cose vadano in un certo modo....chissà :D



L'unica certezza è che ce ne sono altrettanti nel software closed, con l'aggravante che è più difficile scovarli.

Il problema non è l'open, è l'ingegneria del software che ormai ha perso la bussola ( gli hacker che spaccavano il bit non ci sono più e nemmeno avrebbero tempo per spaccare i loro bit, viste le assurde deadline che vengono imposte oggi ).

Non posso che quotarti in tutto!

patch definitiva arrivata anche nei repo debian :)

aggiornato ora :P

Ecco un comodo tool per testare se i vostri servizi CGI sono vulnerabili a Shellshock!

http://www.shielder.it/tools/shellshock.php

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

A me linux mint 15 non risponde proprio nulla digitando da terminale. :confused:

Questo è un discorso che viene fatto spessissimo anche dai guru, tant'è che la volontà di liquidare C ( e soprattutto C++ ) ha fatto nascere Java, C#, ecc... e più recentemente Go e Rust. Risultato? C e C++ sono sempre lì e sempre più forti.


Non si può sostituire un linguaggio che viene compilato (C o C++) con uno interpretato come Java o che non supporta l'intercettazione delle eccezioni come Go (almeno l'ultima volta che ci ho giocato).

In realtà il C++11 ha introdotto tante caratteristiche comuni ai linguaggi moderni e, ormai, non è più "un'estensione ad oggetti del C" anche perché lo scopo del linguaggio non era certo quello.

Non sono i linguaggi, ad ogni modo, a rendere buono e sicuro il software ma i programmatori. Come hai scritto anche tu, oggi si programma troppo velocemente e forse con meno attenzione alla qualità. Questo, almeno, posso confermarlo nella realtà italiana dello sviluppo: pochissimo tempo per l'analisi, cambiamenti costanti di requisiti, figure commerciali che vendono l'impossibile senza nemmeno avere il parere della parte tecnica, sviluppatori poco preparati o con poca esperienza lasciati a sviluppare con scarsa o nulla supervisione.

I risultati si vedono: procedure online spesso poco chiare, macchinose o con molti bug. Dalla PA alle aziende private sono pochi gli esempi di buona programmazione.

Tornando a noi, ti ho risposto perché ci tenevo a precisare che il C++11 ha fatto tantissimi passi in avanti. Se hai tempo o voglia ti consiglio un libro sulla programmazione e sul C++11 in particolare, scritto da chi l'ha inventato:
Bjarne Stroustrup: "Programming: Principles and Practice Using C++ (2nd edition)".
Questa edizione è uscita a giugno del 2014 ed è davvero un bel libro.

Ciao :)

Non si può sostituire un linguaggio che viene compilato (C o C++) con uno interpretato come Java o che non supporta l'intercettazione delle eccezioni come Go (almeno l'ultima volta che ci ho giocato).

Per Java esistono anche compilatori. Ed esistono anche linguaggi ( D ad esempio ) che sono compilati e supportano pure le eccezioni. Ma niente, nisba, C e C++ restano lì.

E alla base ci sono motivi che vanno oltre le eccezioni e la compilazione.


In realtà il C++11 ha introdotto tante caratteristiche comuni ai linguaggi moderni e, ormai, non è più "un'estensione ad oggetti del C" anche perché lo scopo del linguaggio non era certo quello.

Pure Java ha introdotto i generics, ma lo ha fatto dopo, a differenza di C# che è stato progettato tenendo conto anche dei generics. E per questo ci sono schiere di programmatori che dicono C# è migliore di Java.

Per C++ vale lo stesso discorso. Forzare un qualcosa in un sistema che non era stato pensato per quello produce ( spesso ) mostri. Basti guardare a che razza d'accrocchio si sono inventati per implementare i templates.


Non sono i linguaggi, ad ogni modo, a rendere buono e sicuro il software ma i programmatori.


Sono entrambi. Il programmatore è un uomo, ha dei limiti. Non puoi stare lì a farti scoppiare la testa e perdere la vista per intercettare un buffer overflow ben nascosto. Heartbleed, Shellshock e tantissimi altri bug "banali" ne sono l'esempio lampante.


Come hai scritto anche tu, oggi si programma troppo velocemente e forse con meno attenzione alla qualità.


Assolutamente. Nell'industria IT non ci lavorano gli hacker stile anni '70-'80, questo è poco ma sicuro.

Ma il materiale umano questo è, per cui bisogna risolvere il problema lato macchina.



Tornando a noi, ti ho risposto perché ci tenevo a precisare che il C++11 ha fatto tantissimi passi in avanti. Se hai tempo o voglia ti consiglio un libro sulla programmazione e sul C++11 in particolare, scritto da chi l'ha inventato:
Bjarne Stroustrup: "Programming: Principles and Practice Using C++ (2nd edition)".
Questa edizione è uscita a giugno del 2014 ed è davvero un bel libro.

Ciao :)

Non discuto i passi in avanti fatti dal C++, il problema sta nella crescita esponenziale di complessità del linguaggio.

Non a caso si scherza sul fatto che nessun programmatore conosce veramente e al 100% il C++.

C / C++ sono insicuri by design:


Non c'è array bound checking: è troppo facile commettere quel genere di errori! Java e C# danno, correttamente un'eccezione C/C++ vanno in core, o, peggio, hanno "comportamento non definito"
Il C non ha un tipo stringa, ma un accrocchio: un'array di caratteri terminato con 0... se quello 0 lo dimentichi sei fritto! Certo ci sono le sprintf(), ma le funzioni unsafe restano (strcpy, getc, ...) o uno per fare appunto il fico si può mettere a costruire le stringhe a "mano" facendo un bel for :Prrr:
Il tipo stringa di C++ non è realmente molto usato, moltissimi metodi C++ vogliono in ingresso char *!
Le funzioni a parametri variabili sono il diavolo! A parte particolari estensioni è praticamente impossibile sapere quanti argomenti variabili ci sono: o metti prima una variabili che indichi il numero di argomenti o la termini con NULL... peccato che se ti scordi il NULL ti spazzoli tutta la memoria!
E' troppo facile sovrascrivere la memoria di altre funzioni (magari perché avevi una stringa non tappata da qualche parte?)


Un'altra cosa Java usando una macchina virtuale con JIT non ha poi molto da invidiare a C/C++ e, IMHO, i benefici di avere un linguaggio safe by design val bene quel 2-3% di veloci che si può perdere.

Perché vengono ancora usati C/C++? Un po' perché i programmatori del mondo Open Source ci sono affezionatati, ma anche un po' per tutto il codice precedente che esiste e che portare su Java piuttosto che Rust o Go sarebbe un bel c*sino oggettivamente :p