Vulnerabilità in Microsoft GDI+

Vulnerabilità in Microsoft GDI+

Scoperta una vulnerabilità nella gestione dei files JPEG. Vulnerabili decine di software

di pubblicata il , alle 09:39 nel canale Sicurezza
Microsoft
 
I migliori sconti su Amazon oggi
51 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Kralizek16 Settembre 2004, 12:39 #11
cmq da notare che Win XP SP2 e .NET Framework 1.1 SP1 sono esenti da questo bug... quindi basta aggiornare tutto e si va tranquilli!!!
jappilas16 Settembre 2004, 12:45 #12

Re: Bello sono il primo !!!

Originariamente inviato da NetFreeStyle
Speriamo che mentre scrivo non mi frega nessuno !!!
Cmq. altra falla........mha.......domanda, Windows 2000 non viene menzionato...mmmmmmmmm.....devo controllare meglio sul sito microzozz !!!

Bye bye


sgabello16 Settembre 2004, 12:45 #13
Si... ma cazz... io non ho capito una cosa... perchè se il file di sistema incriminato è uno, c'è una sfilza di programmi con la loro singola patch?

SL/\sH16 Settembre 2004, 12:54 #14
Quello che mi lascia allibito non è l'esistenza del bug...


Ciò che mi scandalizza è come viene affrontata la sua correzione !!

Le APPZ vulnerabili, si appoggiano su Gdiplus.dll (e già qui diamo la colpa alle APPZ, non alla libreria che è stata scritta male )

Cosa fa M$ ? Patch su patch per ogni singolo SW che si appoggia su tale libreria... ovviamente SW di terze parti resteranno vulnerabili

Ora mi chiedo... non basterebbe correggere la libreria incriminata ?

Non venitemi a dire che non esiste altra soluzione perchè allora significa che il tutto è stato scritto coi piedi! (una buona caratteristica di un SW sarebbe quantomeno essere un minimo modulare)

Si chiamano librerie apposta xchè così l'SW che c'è dietro lavora in maniera standard e trasparente... ed il bello di ciò è proprio che correggi la libreria senza dover stravolgere tutto!

Un plauso ad M$ che ci stupisce ancora con le sue perle di programmazione...
mavex16 Settembre 2004, 13:14 #15
[B]Originariamente inviato da SL/\sH [/B]
Quello che mi lascia allibito non è l'esistenza del bug...


Ciò che mi scandalizza è come viene affrontata la sua correzione !!

Le APPZ vulnerabili, si appoggiano su Gdiplus.dll (e già qui diamo la colpa alle APPZ, non alla libreria che è stata scritta male )

Cosa fa M$ ? Patch su patch per ogni singolo SW che si appoggia su tale libreria... ovviamente SW di terze parti resteranno vulnerabili

Ora mi chiedo... non basterebbe correggere la libreria incriminata ?

Non venitemi a dire che non esiste altra soluzione perchè allora significa che il tutto è stato scritto coi piedi! (una buona caratteristica di un SW sarebbe quantomeno essere un minimo modulare)

Si chiamano librerie apposta xchè così l'SW che c'è dietro lavora in maniera standard e trasparente... ed il bello di ciò è proprio che correggi la libreria senza dover stravolgere tutto!

Un plauso ad M$ che ci stupisce ancora con le sue perle di programmazione...


Basta leggere il bollettino della microsoft stessa...
Windows XP, Windows XP Service Pack 1, and Windows Server 2003 provide an operating system version of the component that is vulnerable to this issue. Earlier versions of Windows did not provide an operating system version of this component. Therefore, when you install programs that require this functionality on earlier versions of Windows, this component is commonly installed. Typically, when these programs are installed on Windows XP, Windows XP Service Pack 1, or Windows Server 2003 they only use the version that is provided by the operating system, even if they install a copy of the vulnerable component.


Siccome questa libreria c'è soltanto su Windows XP/2003, ogni programma installa la sua versione, cosi da funzionare anche sugli altri sistemi operativi. Quindi bisogna andare a patchare tutti i file gdiplus.dll nel sistema, non solo quello nella cartella system32.
SL/\sH16 Settembre 2004, 13:49 #16
Non vorrei mancarti di rispetto... ma tutto cio ti sembra una cosa da niente ?

Librerie identiche in giro sparse per il sistema, ognuna per il programma che la usa... solo perchè magari una ha un metodo in più

E per fortuna che son librerie!

Capisco perfettamente che alcuni programmi installino la propria libreria se nel sistema non c'è... ma basterebbe un minimo di organizzazione e dire

"piazzare le librerie qui..."

Credo che sia un piccolo sforzo, che qualsiasi programmatore dal più scarso al più esperto dovrebbe fare

A cosa servono le librerie?
Ad avere dei "protocolli" su cui appoggiarsi e lavorare in maniera trasparente al resto.... quindi usare versioni diverse di librerie nello stesso sistema è sostanzialmente un errore di programmazione... come è sostanzialmente un errore (a meno di non aver bisogno di stravolgere qualcosa) creare nuove versioni di lib su cui SW antecedenti non girano

Se le cose fossero fatte in un certo modo ci vorrebbe molto poco:

1) la lib non c'è: il prog mette la sua
2) altri prog controllano se la lib attuale è abbastanza aggiornata per girare... eventualmente la aggiorano (e non ne mettono un'altra fatta da un'altra parte)
3) si trova il bug -> installazione della singola libreria corretta, tutti i prog sono protetti

Il tutto, ripeto, solo se chi scrive ed aggiorna le lib lavora come dovrebbe, stando attento a non crear confusioni ad ogni aggiornamento.

PS:
Non voglio fare il semplicistico, ne creare flame del tipo meglio questo OS meglio quello, per carità, magari il problema è molto più grande di quello che sembra...
Ma IMHO con una programmazione adeguata ed una strutturazione del SW decente, certi problemi sarebbero molto più semplici da risolvere

tutto questo IMHO
jappilas16 Settembre 2004, 14:26 #17
Quello che descrivi è un problema, comunemente descritto come "DLL Hell", di cui sento parlare continuamente
ho l' impressione che se lo si potesse risolvere così facilmente da un momento all' altro, lo si sarebbe già fatto...

i punti che tu proponi mi paiono applicabili in un ambito "ideale" ma un po' semplicistici dal punto di vista pratico... il punto è che una libreria esporta una certa interfaccia per un certo set di funzioni, e il SW che sfrutta quella libreria "si apetta" che funzioni in un certo modo
da una versione all' altra della libreria l' interfaccia può cambiare perchè vengono aggiunte/tolte (a volte anche tolte) funzioni , oppure si può modificare il funzionamento di una certa funzione/metodo: se questo accade i programmi scritti e compilati per una certa versione di quella libreria avranno problemi se la libreria viene sovrascritta da una sua versione diversa richiesta esplicitamente da qualche SW...le altre applicazioni potranno essere br0ken
la soluzione è tenere nel sistema tutte le varianti della libreria richieste, a questo punto non è così irrazionale lasciarle ciascuna nella directory dell' applicazione che la richiede: se non altro si ha la sicurezza che una volta disinstallata l' applicazione, sia "safe" cancellare anche il o i file .DLL che quell' applicazione richiedeva;
invece se tutte le DLL vengono messe sotto system32, imho la probabilità che rimangano lì in eterno è >0 , perchè a volte l' uninstaller non rimuove componenti potenzialmente condivisi e riusati e/o l' utente stesso nel dubbio, sceglie di non cancellare qualora Uninstallshield presenti la finestra di dialogo
SL/\sH16 Settembre 2004, 14:42 #18
Sono d'accordo anche se secondo me con un'attenta analisi della situazione a priori spesso si potrebbe evitare di cambiare interfaccia e rendere le lib "universali" (è il concetto di lib, no ? )

Il discorso dell'uninstaller lo condivido... ma parzialmente: stiamo parlando di una lib che molto probabilmente sarebbe lo stesso presente nel sistema... in quanto è dell'OS e di prodotti dello stesso sviluppatore dell'OS

Poi certo... le lib proprietarie di uno specifico SW è sacrosanto che stiano nelle cartelle del SW in questione..
sirus16 Settembre 2004, 14:46 #19
secondo me l'errore (di avere + copie dello stesso file) non è di MS, in fatti io ho installato parecchi di quei software sul mio pc con xp professional e di file gdiplus.dll ne ho uno nella dir predefinita mentre alcuni programmi di terze parti hanno il medesimo file nella loro directory. quindi prima di parlare sarebbe meglio dare una controllata...
ps hanno fatto tante patch perchè se uno ha installato su win 2000 (che non è affetto dal problema) un soft con il bug allora non puoi installare la patch al so ma al software installato...semplice no
SpyroTSK16 Settembre 2004, 16:18 #20
Il problema secondo me non è molto nell'organizzare le dll il problema è riscrivere windows per delle librerie, poi è un fatto di $, + bachi + versioni usciranno = + clienti dopo, il problema rimane che maggior parte dei programmi oggi in circolazione sarebbero inutili installarli perchè le librerie dll, ocx dde ecc verranno spostate e quindi il programma non funziona +.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^