Come anticipato lo scorso venerdì, questa emissione di sicurezza di febbraio 2009 vede la pubblicazione di 4 bollettini che risolvono un totale di 8 vulnerabilità, tutte non note pubblicamente fino ad oggi tranne quella relativa al bollettino di SQL che è stata oggetto del Security Advisory 961040.
Alcuni dettagli:
Contestualmente ai 4 bollettini è stato anche rilasciato un Security Advisory che consolida i Kill Bits degli ActiveX che non dovrebbero essere invocabili tramite Internet Explorer e quindi vengono disabilitati:
Microsoft Security Advisory (960715) - Update Rollup for ActiveX Kill Bits
Tale aggiornamento aggiunge i nuovi kill bit per i seguenti prodotti non Microsoft:
Lo strumento gratuito di rimozione di malware, il Malicious Software Removal Tool (MSRT), che viene mensilmente proposto agli utenti in questa occasione, questo mese aggiunge la seguente famiglia di malware alla lista di rilevamento:
Per coloro che stessero attivamente usando l'MSRT di gennaio per debellare l'infezione Conficker, potrebbe essere opportuno continuare l'opera di disinfezione con la nuova versione di questo mese, alla luce di alcune ottimizzazioni realizzate nelle operazioni di rilevamento/rimozione.
Aggiornamento del 13/02/2009:
Altri post/risorse correlate:
sarebbe bello che ci spiegassi meglio il MS09-002 (aka CVE-2009-0076)... perche' sembra fantascienza... com'e' possibile che IE crashi, esponga registri & compagnia ed esegua codice iniettato, tramite un mero errato parsing del CSS?? E' fatto cosi male IE , o c'e' dell'altro (non specificato)?
pure il bug sl ms-tnef non e' male cmq... dio sa' xche esista ancora quel astruso formato e pratica di embeddare oggetti ole che poi exchange deve "eseguire" per estrapolarli/rielaborarli.
@bubba: sia detto con tutto il rispetto, non capisco come mai tu ti stupisca del funzionamento di una vulnerabilità di tipo "memory corruption" che interessa il parsing di CSS. Credi che questo componente sia più facile da scrivere degli altri? Credi che gli altri browser ne siano immuni? Se un codice, MS o non MS, non gestisce correttamente l'input, si creano le condizioni per una vulnerabilità di tipo remote code execution, e il tipo di componente interessato fa la differenza solo per i privilegi con cui viene eseguito, non per quello che fa.
Sul problema dei formati astrusi, ti confesso che spesso ce lo chiediamo anche noi :-), ma il problema è sempre che non sappiamo e immaginiamo tutte le decisioni di progetto che hanno guidato tali scelte all'origine, e le considerazioni di compatibilità applicativa che guidano le decisioni di mantenerle di versione in versione.