Flash e la vulnerabilità latente

Due esperti di sicurezza sostengono che molti siti web potrebbero essere sfruttati per lanciare pericolosi attacchi ai danni di tutti gli utenti che utilizzano Flash Player

Mike Murray, chief information security officer di Foreground Security, in questo articolo ha richiamato l’attenzione della comunità di esperti di sicurezza su una vulnerabilità legata a Flash e considerata potenzialmente molto seria. Una vulnerabilità che, secondo l’esperto, non deriva da un bug nel codice di Flash Player ma da alcune regole di sicurezza della tecnologia di Adobe e da come queste vengono interpretate dagli sviluppatori web.

Stando a quanto spiegato da Murray, la debolezza potrebbe essere utilizzata per trasformare in veicoli di diffusione di script maligni la stragrande maggioranza dei siti web che consentono agli utenti di caricare file. Come dimostrerebbe questo video pubblicato da Mike Bailey, ricercatore senior di Foreground, tra le risorse vulnerabili c’era anche Gmail (Google ha recentemente corretto il problema): in questo caso il vettore di attacco era rappresentato dagli allegati email.

“Tra i siti web potenzialmente vulnerabili ci sono quelli di social networking, quelli dedicati alla carriera lavorativa, quelli delle agenzie governative e delle aziende della Fortune 1000”, ha messo in guardia Bailey. “Questa falla è particolarmente insidiosa per il fatto che i contenuti Flash possono essere mascherati da altri tipi di file, come documenti Word ed Excel, immagini o file zip”. L’esperto ha citato come esempio l’eventualità che l’utente di un forum carichi sul server un file che, pur sembrando l’immagine di un avatar, è invece un file Flash maligno capace di compromettere la sicurezza di tutti coloro che semplicemente visualizzino il finto avatar.

Murray e Bailey hanno spiegato che il problema risiede nella same-origin policy di Flash ActionScript e nel modo in cui questa viene generalmente interpretata dagli sviluppatori. “Le regole alla base della same-origin policy di ActionScript sono molto simili a quelle di JavaScript: un oggetto Flash può accedere esclusivamente ai contenuti che risiedono sullo stesso dominio da cui è stato eseguito lo script” spiegano i due ricercatori. “La differenza più importante è che gli oggetti Flash non sono pagine web. Non c’è bisogno di iniettare un oggetto Flash all’interno di una pagina web per eseguirlo: è sufficiente caricare il contenuto. Ciò significa che se io metto un oggetto Flash sul tuo server, posso eseguire degli script nello stesso contesto del tuo dominio”.

Interrogata sulla questione, Adobe ha dichiarato a Foreground che “sfortunatamente non c’è una soluzione semplice”, e il motivo è che “è molto difficile risolvere il problema senza compromettere il funzionamento dei contenuti legittimi sparsi per il Web”. La mamma di Flash ritiene sia molto più proficuo “educare” sviluppatori e web designer a comprendere tutti gli aspetti della same-origin policy di Flash ActionScript, in modo da aggirare il problema in fase di creazione dei siti web.

Murray ha precisato che al momento non ci sono segnalazioni di attacchi che facciano leva su questa debolezza, tuttavia “ci sono prove che dimostrano come i cracker si stiano muovendo in questa direzione”.

Alessandro Del Rosso

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Star scrive:
    Il vero problema di SPDY...
    ...lo scoprite leggendo nella documentazione il paragrafo: "Goals for SPDY", per l'esattezza il punto che dice:"To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."Tutti vogliono connessioni sicure e criptate. Ma vi siete mai chiesti perché molti siti che devono/vogliono garantire solo la sicurezza dell'autenticazione ma non dei contenuti trasferiti (es. Hotmail) usano l'HTTPS solo in fase di login per generare un token e poi passano all'HTTP ?Criptare il traffico ha un costo in termini di tempi di elaborazione non indifferente. I grossi provider non a caso fanno uso di moduli hardware dedicati nei propri server per questi compiti. Ma persino tali moduli non hanno potenze di calcolo infinite.Immaginatevi ora se tutti i server web decidessero di supportare SPDY come protocollo. Qualsiasi pagina web, anche la homepage di un'azienda o un blog, un forum o quant'altro nonché tutti gli elementi grafici e le applicazioni Flash/Java ad essi connessi verrebbero criptati. Per non parlare dei file da scaricare, magari centinaia di Mega o Giga... tutto criptato da specifiche.Quanto credere che reggerebbero i server web attuali, anche i più potenti ? Ed upgradarli per riuscire a reggere un simile carico computazionale quanto pensate che verrebbe a costare ?
    • Steve Robinson Hakkabee scrive:
      Re: Il vero problema di SPDY...
      Fra 3 anni sarà la norma, ricorda la legge di moore....
    • iRoby scrive:
      Re: Il vero problema di SPDY...
      Potrebbe anche essere NSA ed i governi a volere dati di email passare in chiaro nelle connessioni...
    • Ubunto scrive:
      Re: Il vero problema di SPDY...
      - Scritto da: Star
      Tutti vogliono connessioni sicure e criptate. Ma
      vi siete mai chiesti perché molti siti che
      devono/vogliono garantire solo la sicurezza
      dell'autenticazione ma non dei contenuti
      trasferiti (es. Hotmail) usano l'HTTPS solo in
      fase di login per generare un token e poi passano
      all'HTTP?Probabilmente perché su servizi gratuiti il loro interesse è quello di rendere sicura l'acquisizione delle credenziali d'acXXXXX.Immagino che con caselle e-mail a pagamento invece si possa avere una connessione completamente criptata.
  • Mattia scrive:
    Basta che sia un protocollo open
    Come da titolo :)
  • spectator scrive:
    il solito show di luci e colori di guggl
    SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective of the server business logic or application API, nothing has changed. To achieve this, all of the application request and response header semantics are preserved. SPDY introduces a "session" which resides between the HTTP application layer and the TCP transport to regulate the flow of data. This "session" is akin to an HTTP request-response pair. The following changes represent the differences between SPDY and HTTPe qui ci si rende conto delle "belle idee" di guuglovvero questa idea geniale che dovrebbe risolvere la velocita' dell'http produrra' (una persona con un minimo di conoscenza informatica potrà comprendere) dei bellissimi imbutoni a livello di tcp/ip eh si sono proprio dei geni.RIVOGLIO altavista!
    • Gattazzo scrive:
      Re: il solito show di luci e colori di guggl
      dei bellissimi imbutoni a livello di tcp/ip ??? Ci facci comprendere, plis ...
    • ruppolo scrive:
      Re: il solito show di luci e colori di guggl
      Concordo. La latenza aiuta a rendere fluido il traffico.
    • pinco pallino scrive:
      Re: il solito show di luci e colori di guggl
      - Scritto da: spectator
      RIVOGLIO altavista!Altavista c'è ancora.Altavista ha una interfaccia più pesante di quella di Google.
      • angros scrive:
        Re: il solito show di luci e colori di guggl
        Altavista usa lo stesso indice di Yahoo (a quanto dice wikipedia), quindi ti fornirebbe gli stessi risultati; tanto vale usare yahoo, a questo punto.
        • pinco pallino scrive:
          Re: il solito show di luci e colori di guggl
          - Scritto da: angros
          Altavista usa lo stesso indice di Yahoo (a quanto
          dice wikipedia), quindi ti fornirebbe gli stessi
          risultati; tanto vale usare yahoo, a questo
          punto.Forse gli stessi risultati ma non nello stesso modo, tantopiù che gli stessi risultati per esempio non sono supportati dal plugin di Web Of Trust.Quindi è effettivamente meglio usare Yahoo (che per la cronaca fornisce risultati migliori del vecchio altavista).
    • pabloski scrive:
      Re: il solito show di luci e colori di guggl
      magari il problema sono proprio le latenze non ti pare?se poi telecom non ce la fa a raggere già il traffico attuale, beh, google che colpa ne ha?google sta nel 2010, se noi qui siamo nel 1910 non è un problema di googlel'idea di google riduce il consumo di banda e abbassa le latenze e questo è un bene
  • free for all scrive:
    un altro flash
    ..stesso discorso fatto per flash: siti che caricano contenuti piu' velocemente, contenuti piu' performanti, affiancamento e non sostituzone dell'html... tutto gia' sentito, ecco a voi un altro plugin, l'ennesimo.., per carita' sara' pure tutto vero, veloce bello leggero etc etc, ma apparentemente (sottolineato) non e' lo standard che viene sostituito, ma semplicemente un addon da pluggare nei browsers.
    • Be&O scrive:
      Re: un altro flash
      Header compressi, significa che i Webserver devono supportare l'invioche inizialmente i browser possano supportarli grazie ad un plug-inquesto è vero, ma alla fine con le release nuove la cosa verrebbeintegrata a livello di codice del Browser, e onestamente andrebberivisitato anche il protocollo TCP/IP, ormai è come i PC il collodi bottiglia è sempre più legato ai protocolli di base che sono fermiall'epoca degli anni 80.
      • rido per non piangere scrive:
        Re: un altro flash
        Guarda che i protocolli attuali sono piu' leggeri che quelli che vorrebbero fare...A meno che vuoi usare UDP, ma non credo sia una buona idea...
      • gerlos scrive:
        Re: un altro flash
        - Scritto da: Be&O
        andrebbe
        rivisitato anche il protocollo TCP/IP, ormai è
        come i PC il
        collo
        di bottiglia è sempre più legato ai protocolli di
        base che sono
        fermi
        all'epoca degli anni 80.Siamo sicuri?No, lo dico perché TCP/IP, HTTP e compagnia sono stati progettati in un periodo dove era lenta la trasmissione di ogni singolo byte, e le risorse erano limitate. Detto questo, mi aspetto che oggi non siano i protocolli il problema, visto che abbiamo reti di 3-4 ordini di grandezza più veloci e i sistemi innumerevolmente più potenti e veloci!Certo, se un protocollo era nato per fare una cosa e due decenni dopo viene usato per scopi diversi, è ragionevole pensare a rinnovarlo...Boh, staremo a vedere... speriamo solo che pubblichino tutte le specifiche in modo aperto!
    • Skhammy scrive:
      Re: un altro flash
      No.L'articolo parla di protocollo.Il protocollo non è un plugin.Per cortesia..
  • boh. scrive:
    uhm...
    1-come hanno fatto a testarlo sui 25 principali siti globali se questi usano l'http? mica da una aprte puoi avere http e dall'altra spdy2-le adsl italiane vanificheranno tutto
    • kaihiwatari scrive:
      Re: uhm...
      1- Basta averne una copia dei siti nel loro server o chiedere a quei 25 siti di partecipare alla sperimentazione. Più probabile sia la prima...2- Non credo sia così: grazie alle tecniche di compressione e multi-connessione nuove accennate nell'articolo, anche noi poveri italiani potremo avere benefici da questo nuovo protocollo.Se magari permettessero anche una crittografia dei dati, soprattutto per quanto riguarda i dati inviati da client a server (password e altri dati sensibili) come fa l'https, ma con molta più "semplicità tecnica", direi che arriverà a sostituire l'http egregiamente.-----------------------------------------------------------Modificato dall' autore il 13 novembre 2009 20.52-----------------------------------------------------------
      • Star scrive:
        Re: uhm...
        La crittografia la permette... anzi... la rende obbligatoria da specifiche (leggiti la documentazione).Ma questo è il problema !La crittografia andrebbe usata solo ed esclusivamente quando vengono inviati dati riservati (login, carte di credito, informazioni personali o confidenziali ecc...)... se devo trasferire il logo di una società, lo sfondo di un sito, una musica di sottofondo, una homepage, una pagina informativa generica e via dicendo non serve oberare i server web di lavoro del tutto inutile (criptare porta via moltissimo CPU time).
        • kaihiwatari scrive:
          Re: uhm...
          Ammetto di non aver letto la documentazione, appena avrò un po' di tempo gli darò un'occhiata!Beh il tuo "moltissimo" mi sembra un po' troppo: anche le odierne CPU per netbook possono fare senza sforzi tali lavori di crittografia.E poi, crittografare anche i dati non proprio riservati non mi sembra esattamente uno spreco: che gli altri si facciano un po' gli affari propri su cosa visito o no! ;D
Chiudi i commenti