Pagina 2 di 2 primaprima 1 2
Visualizzazione dei risultati da 11 a 16 su 16
  1. #11
    Quote Originariamente inviata da andrea.paiola Visualizza il messaggio
    beh ma scusa io non lo considererei sicuro un sistema che ti permette da remoto e senza controlli di settare variabili d'ambiente...
    Non è che da remoto puoi settare variabili d'ambiente a caso, CGI specifica esattamente quali. L'imprudenza è di bash che cicla sulle variabili e fa l'eval di qualunque cosa che assomiglia ad una funzione, è andarsi a cercare rogne.
    e più che Apache sarebbe PHP, in questo caso.
    PHP era un esempio di soluzione sbagliata ad un problema di sicurezza. Se (come fa il tizio di quell'articolo) chiedi che ti vengano escapati a monte dei dati vuol dire che hai già perso, dato che:
    1) significa che a valle non sai distinguere dati da codice, la madre di tutti i problemi di sicurezza (vedi SQL injection, un non-problema che deriva dalla gestione intrinsecamente sbagliata che i programmatori incompetenti fanno dei dati delle query SQL);
    2) stai cercando di risolvere il problema nel posto sbagliato, visto che puoi fare l'escaping solo per un determinato linguaggio (PHP lo fa(ceva) per SQL, Apache secondo questa logica malata lo avrebbe dovuto fare per bash), quando a valle potrebbe esserci qualunque cosa: uno script CGI può essere scritto in qualunque linguaggio, e Apache non può saperlo a priori, a meno di non andarsi a guardare lo shebang e introdurre escape differenti a seconda del linguaggio - pura follia; si riproporrebbe appunto il problema delle "magic quotes", per cui ti ritrovi roba escapata per un caso d'uso specifico, e in tutti gli altri casi devi de-escaparla per riottenere i dati originali.
    Poi certo sarebbe ottimo controllare le variabili d'ambiente quando le usi, ma in prima istanza non le farei settare.
    No, non le devi controllare, devi semplicemente farti gli affari tuoi e non cercare di fare l'eval di cose a cazzo, punto.
    Amaro C++, il gusto pieno dell'undefined behavior.

  2. #12
    quali sono i danni che un PC remoto puo'/poteva fare?

  3. #13
    Quote Originariamente inviata da sacarde Visualizza il messaggio
    quali sono i danni che un PC remoto puo'/poteva fare?
    Esecuzione di codice arbitrario (con le credenziali dell'utente sotto cui gira lo script CGI).
    Amaro C++, il gusto pieno dell'undefined behavior.

  4. #14
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    No, non le devi controllare, devi semplicemente farti gli affari tuoi e non cercare di fare l'eval di cose a cazzo, punto.
    Difatti, l'ultima patch fa la cosa corretta: non fa l'eval di variabili d'ambiente a caso, ma solo di quelle che riconosce come "sue" fin dal nome.
    Amaro C++, il gusto pieno dell'undefined behavior.

  5. #15
    Utente di HTML.it L'avatar di pilovis
    Registrato dal
    Mar 2001
    Messaggi
    3,276
    Adesso e' uscita anche la vulnerabilita' “POODLE” SSLv3 (ma escono tutte adesso oppure fino ad ora hanno dormito?)

    Aggiornate quanto prima libss, libssl-dev e openssl

    https://www.digitalocean.com/communi...-vulnerability
    Ultima modifica di pilovis; 18-10-2014 a 09:30
    Progettista elettronico, appassionato di informatica dal 1982, sistemista Linux dal 2002, sono consulente tecnico del Giudice per le indagini preliminari, valuto richieste di consulenza, in ambito Voip/Telefonia anche con grado di sicurezza militare.

  6. #16
    Più che altro, disabilitare SSLv3; dato che è un baco di progettazione del protocollo SSL3 non si può patchare.
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.