Un RAR può uccidere Norton Antivirus

Un file RAR creato ad hoc da un cracker potrebbe causare il crash di molti antivirus di Symantec, incluso il diffusisissimo Norton, e aprire una breccia di sicurezza nel sistema. Ancora nessuna patch


Roma – Un componente alla base di molti prodotti antivirus di Symantec contiene alcune pericolose vulnerabilità di sicurezza che, secondo gli esperti, potrebbero dar modo ad un cracker di compromettere un sistema da remoto.

Le falle, tutte di tipo heap overflow, si trovano all’interno della libreria Dec2Rar.dll utilizzata dagli antivirus di Symantec per decodificare i file compressi con il celebre programma di compressione RAR. Lo scopritore dei bug, Alex Wheeler di Rem0te.com , ha spiegato che un aggressore potrebbe sfruttare le debolezze creando uno speciale file RAR che, una volta aperto dall’antivirus, causa un buffer overflow ed esegue del codice.

“Queste vulnerabilità possono essere sfruttate da remoto, senza alcuna interazione dell’utente, e attraverso protocolli comuni come SMTP”, ha scritto Wheeler in questo advisory .

Secondo il ricercatore, i prodotti di Symantec interessati dal problema sono oltre una decina, e comprendono varie versioni ed edizioni di Symantec Norton Antivirus, Symantec Norton Internet Security, Symantec Norton System Works, Symantec Web Security, Symantec AntiVirus, Symantec BrightMail AntiSpam, Symantec Client Security e Symantec Gateway Security. L’elenco completo viene riportato qui da FrSIRT.

Nel momento in cui si scrive Symantec non ha ancora rilasciato alcuna patch. In attesa che ne venga pubblicata una, Wheeler suggerisce agli utenti di antivirus Symantec di disattivare la scansione dei file RAR.

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

  • Anonimo scrive:
    MEtodo più corretto.
    Sarebbe stato più intelligente fissare un test di benchmark libero.Si lancia il benchmark sulla propria infrastruttura e si paga a seconda al risultato.Il rapporto costo/prestazioni sarebbe molto più semplice da calcolare ancor prima dell'acquisto della licenza.
    • Anonimo scrive:
      Re: MEtodo più corretto.
      Lascia perdere avevano già fatto le licenze a MHz, con la velocità con cui accelerevano i processori e la lentezza con la quale aggiornavano il listino ho fatto venire un'infarto ad un cliente dopo avergli fatto un preventivo nell'ordine degli 800 milioni di lire...
    • Anonimo scrive:
      Re: MEtodo più corretto.
      Simpatica la tua proposta! Peccato che i benchmark dipendono esclusivamente dalle applicazioni che ruotano attorno ad oracle. Per spiegarci meglio, di solito viene usato come db per un'applicazione sviluppata da una società (che di solito è la stessa che acquista il database oracle). Quindi, se uno volesse truccare i benchmark basta far piantare la propria applicazione e chiedere alla oracle che ti facciano pagare di meno perchè quella versione del loro db non va un kaiser. E tu pensi che la oracle risponda, "si certo, anzi facciamo cosi', fate 1 offerta!".Ciao pischellino, vai a nanna che domattina c'e' scuola!- Scritto da: Anonimo
      Sarebbe stato più intelligente fissare un test di
      benchmark libero.

      Si lancia il benchmark sulla propria
      infrastruttura e si paga a seconda al risultato.

      Il rapporto costo/prestazioni sarebbe molto più
      semplice da calcolare ancor prima dell'acquisto
      della licenza.
  • Anonimo scrive:
    Ma quale ORACLE
    ma quale oracolo io uso Postgresql un DB gratuiticoe performante.
    • Anonimo scrive:
      Re: Ma quale ORACLE
      - Scritto da: Anonimo
      ma quale oracolo io uso Postgresql un DB
      gratuitico
      e performante.se volevi fare l'avvocato del software libero avresti dovuto citare maxdb e non postgres, che per quanto sia robusto non e' paragonabile a prodotti di classe enterprise come oracle, maxdb o db2;riesci a gestire con postgres un db di una decina di TByte?
      • Anonimo scrive:
        Re: Ma quale ORACLE
        - Scritto da: Anonimo

        - Scritto da: Anonimo

        ma quale oracolo io uso Postgresql un DB

        gratuitico

        e performante.

        se volevi fare l'avvocato del software libero
        avresti dovuto citare maxdb e non postgres, che
        per quanto sia robusto non e' paragonabile a
        prodotti di classe enterprise come oracle, maxdb
        o db2;
        riesci a gestire con postgres un db di una decina
        di TByte?eh già tutti devono gestire db di una 10 di terabyte.............
        • Anonimo scrive:
          Re: Ma quale ORACLE
          - Scritto da: Anonimo

          - Scritto da: Anonimo



          - Scritto da: Anonimo


          ma quale oracolo io uso Postgresql un DB


          gratuitico


          e performante.



          se volevi fare l'avvocato del software libero

          avresti dovuto citare maxdb e non postgres, che

          per quanto sia robusto non e' paragonabile a

          prodotti di classe enterprise come oracle, maxdb

          o db2;

          riesci a gestire con postgres un db di una
          decina

          di TByte?

          eh già tutti devono gestire db di una 10 di
          terabyte.............Guarda ti do' ragione, quello di prima ha detto una bischerata anche secondo me, il punto casomai è che se uno ha la necessità di avere alte prestazioni su tempi di risposta elevato numero di transazioni al secondo, alllora mio caro ti assicuro che postgres non ti basta piu' ed hai bisogno di andare su roba oracle (tanto in questi casi hai anche dei contratti di assistenza che ti permettono di sbolognare delle beghe a loro quando il db non va e ti assicuro che anche la oracle non è affatto esente da rilasciare software senza bug!).
      • Anonimo scrive:
        Re: Ma quale ORACLE
        - Scritto da: Anonimo
        se volevi fare l'avvocato del software libero
        avresti dovuto citare maxdb e non postgres, che
        per quanto sia robusto non e' paragonabile a
        prodotti di classe enterprise come oracle, maxdb
        o db2;
        riesci a gestire con postgres un db di una decina
        di TByte?Volendo si, perché? Hai tutti quei dati? Provalo e vedi tu stesso.
        • Anonimo scrive:
          Re: Ma quale ORACLE
          - Scritto da: Anonimo
          - Scritto da: Anonimo

          se volevi fare l'avvocato del software libero

          avresti dovuto citare maxdb e non postgres, che

          per quanto sia robusto non e' paragonabile a

          prodotti di classe enterprise come oracle, maxdb

          o db2;

          riesci a gestire con postgres un db di una
          decina

          di TByte?

          Volendo si, perché? ma conosci postgres? sai qual'e' la dimensione massima supportata per un singolo db? evidentemente no
          • Anonimo scrive:
            Re: Ma quale ORACLE
            Non è solo la dimensione massima del DB. Oracle offre varie funzionalità come tabelle/indici avanzati (object-relational, indici full text e bitmap), funzionalità per datawarehouse (partizionamento delle tabelle, viste materializzate, OLAP ecc.), clustering e molto altro (Intermedia, Spatial, Advanced queueing, ecc.).Più che un semplice "storage" dei dati, è una piattaforma di sviluppo per applicazioni DB complesse. E questo incide sul prezzo.
          • FDG scrive:
            Re: Ma quale ORACLE
            - Scritto da: Anonimo
            Più che un semplice "storage" dei dati, è una
            piattaforma di sviluppo per applicazioni DB
            complesse. E questo incide sul prezzo.Questo puntroppo molti non riescono a capirlo perché pensano che il DB sia sempre e solo quell'oggetto dove fai "select ... from... where...". A questo punto, a che serve postgres visto che c'è SQLite? :D
  • Federikazzo scrive:
    io non capisco...
    ...perché se ho una cpu multicore devo pagare una licenza che mi costa 3/4/5 volte di più?non è pur sempre UNA SOLA cpu? mica posso farci girare 64 sistemi operativi diversi, con 1534 applicazioni diverse su 78902 terminali diversi...qualcuno mi spieghi, per favore.non che io debba avere a che fare con questi tizi, visto che FORTUNATAMENTE non ho l'esigenza. però è solo per capire in base a quale principio 1 core = 1 cpu o una frazione di essa...
    • Anonimo scrive:
      Re: io non capisco...
      Tu non devi capire, devi solo aprire il portafoglio. E' questo che loro capiscono... peccato che dall'altra parte il messaggio che giunge è che da questa spirale di sanguisughe non si esce più se non piratando
    • FDG scrive:
      Re: io non capisco...
      - Scritto da: Federikazzo
      però è solo per capire in base a quale principio
      1 core = 1 cpu o una frazione di essa...Perché se piazzi una installazione di Oracle su una macchina con 8 processori invece che su 8 macchine differenti, Oracle perdere il guadagno relativo a 7 licenze. Idem, se prendi una macchina con due processori dual-core, invece che una con 4 processori... ammesso che si possano considerare equivalenti, che è il nocciolo della questione.L'alternativa è avere la licenza per utente che accede in contemporanea al DB. Ma non so se sia tanto meglio. Comunque, se arrivi ad oracle, vuol dire che sei arrivato ad affrontare problemi di una certa dimensione. Perché in caso contrario non ha senso andare a spendere tutti questi soldi, visto che ci sono alternative che hanno un costo decisamente pià basso (es.: postgres).==================================Modificato dall'autore il 21/12/2005 9.35.29
    • Anonimo scrive:
      Re: io non capisco...
      I database di fascia alta sono sempre state fra le applicazioni più esose di risorse, fra CPU, RAM e I/O.Quando internet è diventato ubiquo, i modelli di licenza "per utente" non erano più adeguati - come fa Amazon o Punto Informatico a pagare "per utente"? Quindi si sono inventati la "licenza per processore", visto che in genere il numero di processori è suppergiù proporzionale al carico della macchina. Ovvio che le CPU multicore li spiazzano, perché se è anche vero che una CPU multicore magari non ha la stessa potenza di due CPU separate, probabilmente un po' di potenza in più l'ha comunque e potrebbero permettere di avere server DB di fascia alta con meno CPU - visto che comunque diventano più veloci - con conseguente calo degli introiti...Alla luce di quello che fa MS con SQL Server non mi pare una politica azzeccata, visto anche che Oracle in genere gira su hardware più potente.
Chiudi i commenti