Vulnerabilità in Google Desktop

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/sicurezza/21428.html

Una vulenrabilità di sicurezza è stata individuata in Google Desktop: fortunatamente il metodo attraverso cui attuare un attacco non è semplice ma la diffusione del tool impone cautela

Click sul link per visualizzare la notizia.

[powerpc]

mai usato e mai sentita la necessità di farlo...

cmq un sw senza falle di sicurezza deve ancora essere compilato (ammesso che mai ce ne sarà uno davvero blindato)

[k0nt3]

Originariamente inviato da powerpc

mai usato e mai sentita la necessità di farlo...

cmq un sw senza falle di sicurezza deve ancora essere compilato (ammesso che mai ce ne sarà uno davvero blindato)

int main(int argc, char[] *argv)
{
    return 0;
}

adesso lo compilo

[cionci]

Mi sa che non ti compila

[powerpc]

Originariamente inviato da Hitman079

sempre meglio di microsoft desktop search

si si va bè , si sa, peggio di MS non c'è nulla...
ma meglio di Gdesktop c'è... non mettere nulla

Originariamente inviato da k0nt3

int main(int argc, char[] *argv)
{
    return 0;
}

adesso lo compilo

[k0nt3]

Originariamente inviato da cionci

Mi sa che non ti compila

mamma mia! dovrebbero vietare l'uso di java perchè causa dipendenza.. oppure scrivere "java uccide" sulla virtual machine!
siamo alla seconda revisione del software perfetto quindi:

int main(int argc, char *argv[])
{
    return 0;
}

parlando della vulnerabilità comunque mi sembra sia una cosa un pò complicatina da attuare.. non credo che possa mietere molte vittime, comunque è da correggere alla svelta

[blackshard]

Originariamente inviato da k0nt3

int main(int argc, char[] *argv)
{
    return 0;
}

adesso lo compilo

Sai che anche questo semplice codice potrebbe essere soggetto ad exploit? Il puntatore a puntatore *argv[] (o anche **argv) potrebbe essere gestito male dal compilatore nel caso, per esempio, di una stringa in entrata troppo lunga. Da lì un buffer overflow...

Questo non vuole essere un tecnicismo fine a se stesso, ma lo dico solo per far rendere conto a chi non è esperto di programmazione che, oltre agli "errori" di programmazione dei programmatori, ci sono anche gli errori indiretti fatti da altri programmatori, e sono tutti difficilmente scovabili. Tutto per ribadire sempre il concetto che il software sicuro semplicemente non esiste e che le gare fra "è più sicuro questo invece di quello" sono assolutamente da newbie.

[nicgalla]

bella la tua osservazione Blackshard (purtroppo la mia "programmazione" si limita a VB6.. d'altronde x quelle poche volte che mi serve va bene), incredibile come ci possa essere pericolo di vulnerabilità da funzioni così semplici.
Evidentemente ci vorrebbe una maggiore perizia da parte dei compilatori, ma se non erro la tecnologia No Execute delle CPU più recenti dovrebbe impedire l'esecuzione di codice in presenza di buffer overflow...

[Zenon]

io ho un altro problema con G Desktop:se ne avviano tre di cui 1 è quello che vedo mentre gli altri due non so cosa fanno. Stà di fatto che quest'ultimi mi occupano tutta la cpu rallentando paurosamente il pc. Ovviamente se vado in task chiudo queste due appliacazioni e risolvo il problema ma...beh,non c'è un modo un pò più definitivo(senza eliminare il programma xchè per il resto mi ci trovo bene)di risolvere l'inconveniente?!

[MEX84]

Originariamente inviato da nicgalla

...ma se non erro la tecnologia No Execute delle CPU più recenti dovrebbe impedire l'esecuzione di codice in presenza di buffer overflow...

In effetti se gestito correttamente dal sistema operativo (XP SP2 se non sbaglio) non dovrebbe essere ammesso buffer overflow. Se però k0nt3 fa riferimento al linguaggio Java, dev'essere la virtual machine a gestire tale eventualità e qui si torna al discorso di blackshard: il programma viene studiato per essere sicuro e poi si scopre un bug nella VM

[k0nt3]

@blackshard grazie per aver segnalato questa possibile falla nel mio programma perfetto... e così siamo già alla terza revisione!! l'ho completamente riscritto in ASM per evitare il problema che affliggeva la versione in C

NOP

[MEX84]

Originariamente inviato da Zenon

io ho un altro problema con G Desktop:se ne avviano tre di cui 1 è quello che vedo mentre gli altri due non so cosa fanno. Stà di fatto che quest'ultimi mi occupano tutta la cpu rallentando paurosamente il pc. Ovviamente se vado in task chiudo queste due appliacazioni e risolvo il problema ma...beh,non c'è un modo un pò più definitivo(senza eliminare il programma xchè per il resto mi ci trovo bene)di risolvere l'inconveniente?!

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

[k0nt3]

Originariamente inviato da Zenon

io ho un altro problema con G Desktop:se ne avviano tre di cui 1 è quello che vedo mentre gli altri due non so cosa fanno. Stà di fatto che quest'ultimi mi occupano tutta la cpu rallentando paurosamente il pc. Ovviamente se vado in task chiudo queste due appliacazioni e risolvo il problema ma...beh,non c'è un modo un pò più definitivo(senza eliminare il programma xchè per il resto mi ci trovo bene)di risolvere l'inconveniente?!

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

[blackshard]

Originariamente inviato da k0nt3

@blackshard grazie per aver segnalato questa possibile falla nel mio programma perfetto... e così siamo già alla terza revisione!! l'ho completamente riscritto in ASM per evitare il problema che affliggeva la versione in C

NOP

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

[Mitridas]

Che mi dite di questo?

void main()
{;}

[Pettinato]

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.

[JohnPetrucci]

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.

[kaharoth84]

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..

[xeal]

@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!

[MenageZero]

Originariamente inviato da Hitman079

sempre meglio di microsoft desktop search

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"