Vulnerabilità in Google Desktop

Io non uso Google Desktop, ma una volta mi è capito un problema simile con un altro programma e ho scoperto che nell'elenco dei programmi da lanciare allo startup (Start->esegui->msconfig->startup) era linkato due volte. Ho disattivato una delle due voci e ho risolto il problema.
Fammi sapere se funziona

credo che stia tentando di indicizzare i files.. è un pò il suo lavoro
non è detto che un programma debba per forza corrispondere a un solo processo

EDIT: ho letto sopra.. ovviamente può essere anche un problema serio, io al momento non ho gDesktop per verificare

Fantastico Questa versione 3.0 è decisamente esente da falle
Ed implementa tutte le funzionalità della versione originale anche

Che mi dite di questo?

void main()
{;}

Non concordo con quello che dice blackshard per quanto riguarda il codice postato in precedenza(a parte char[] *argv che è errato), non è bucabile.

Argv e argc è vero che li comandiamo ma in quel caso il programma non li gestisce in maniera errata (non li gestice proprio) c'è solo un return 0.

Che sfiga, proprio oggi l'ho installato per la prima volta, e devo dire che è utilissimo, anche se l'indicizzazione non la ritengo indispensabile per i miei usi e difatti ho disabilitato tutte le opzioni inerenti questa voce.
Trovo molto utile questo programma per i vari tool informativi, meteo, etc.

x JohnPetrucci.. allora installati una sideBar.. c'è ne sono un sacco freeware... se non usi l'indicizzazione googleDesktop nn ti serve a niente...

cmq io uso google desktop e mi trovo benissimo.. naturalmente ho settato sulle preferenze di non mantenere tracce su internet e non ho indicizzato cronologia e file recenti, inoltre ho tolto la funzione che ti fa cercare i files cancellati..
insomma secondo me con opportuni accorgimenti di configurazione lo si può rendere un pò più "sicuro", almeno per la privacy locale.

per quanto riguarda la falla di sicurezza potrebbe essere grave come dice l'articolo sui quei sistemi dove gds viene preinstallato (vedi sistemi DELL). Ad esempio università sapienza-->lab tiburtina --> nuovo lab -->tutti sistemi dell con gds preinstallato.

ma d'altronde se non preinstallassero certe cose non potrebbero vendere a quel prezzo i sistemi... è il mercato..

@Pettinato

Sei cascato in un piccolo "tranello" della programmazione (chiamiamolo così, in realtà è un piccolo errore di logica): non occorre gestire gli argomenti del main per avere dei problemi con eventuali buffer overflows, perchè comunque se il programma viene eseguito passando dei parametri, questi da qualche parte devono pur finire, e un eventuale buffer overflow porterebbe la parte eccedente il limite previsto ma mal gestito (o non gestito) a "sporcare" (=sovrascrivere) aree di memoria che possono contenere dati (= "falsi" i risultati dell'elaborazione, anche se in questo caso non fai niente - in realtà è un po' più complicato), oppure istruzioni, ed è qui che nascono i problemi, perchè se sovrascrivi un'istruzione con dei dati, allora incasini il programma, ma in pratica ottieni "solo" un errore (tipicamente il dato sarà riconosciuto come istruzione non valida), ma se la sovrascrivi con una istruzione maligna possono essere cavoli (e se l'area sovrascritta non appartiene al programma specifico, ma ad esempio al sistema operativo che gestisce il passaggio dei parametri al programma, è ancora peggio).

In realtà, questo caso specifico non dovrebbe essere un grosso problema, nel senso che comunque, almeno in una fase iniziale, la lettura dei parametri dovrebbe essere effettuata dal sistema operativo, che difficilmente la gestirà male (tipicamente, ragiunto un certo limite dovrebbe troncare e scartare tutti quelli successivi), però basta a far capire quanto siano pericolosi certi dettagli apparentemente insignificanti (e se poi il bug dovesse essere nel compilatore, son dolori, perchè è più difficile scovarli), quanto sia sbagliato dare per scontato che qualcosa andrà sicuramente per il verso giusto (Monroe docet ), e quanto certe critiche su software complessi abbiano il peso specifico delle chiacchiere da bar.

Comunque, soluzioni come quella di Java, che gestisce la memoria per conto del programma, sono tendenzialmente più sicure, perchè ti affidi ad un layer software che ha funzioni comunque limitate e più facili da monitorare, risolvendo certi problemucci in un modo almeno statisticamente più efficiente rispetto ad avere mille miliardi di programmi diversi, che devono fare tutto da soli (statisticamente avremo più errori, e complessivamente una maggiore difficoltà nel risolverli tutti).

@ k0nt3

Ehm, non vorrei infierire () ma temo che un sistema operativo abbia bisogno di qualche altra istruzione per poter effettuare il context switch, creare e lanciare il processo, quindi o scrivi qualcos'altro in assembly, facendo molta attenzione, oppure inserisci la tua NOP in un listato da compilare, e ritorniamo alla questione dei bug che non si conoscono: il colmo sarebbe provocare un crash di sistema cercano di non fare niente!

certo, esce la news "bug y nel programma x" e qusto implica che la più immediata, ovvia, logica, stringente, cosa da dire è esprimere l'originalissimo concetto "il programma analogo di ms x' è peggio di x"

@xeal

non sono cascato in nessun tranello, infatti anche tu mi dai ragione:

"In realtà, questo caso specifico non dovrebbe essere un grosso problema, nel senso che comunque, almeno in una fase iniziale, la lettura dei parametri dovrebbe essere effettuata dal sistema operativo, che difficilmente la gestirà male "

Io parlavo del caso specifico cioè quella main con solo return 0 è innocua.

Non parlo del problema Buffer Overflow che è stra conosciuto e stra documentato.

Ripeto quella funzione non è bucabile.