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.

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)

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

Mi sa che non ti compila ;)

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


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


adesso lo compilo

:D

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

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.

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

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

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

@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

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

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 :fagiano:
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 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 :D Questa versione 3.0 è decisamente esente da falle :cool:
Ed implementa tutte le funzionalità della versione originale anche :D

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 :D), 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 (:p) 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! :sofico:

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"
:rolleyes:

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

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.

Infatti io parlavo di gestione da parte del compilatore. Seppure nel codice non fanno niente, il compilatore dovrà come minimo fare il parsing della stringa sulla linea di comando (per ottenere argc, quantomeno). Poi immagino che qualcuno dovrà copiarsi la riga di comando in qualche buffer locale, e qui un'altra grana.
Per carità, se chi ha fatto il compilatore con cognizione fa tutto subito e senza problemi, ma se uno pretende di copiare una stringa da 200 byte in un buffer statico da 128...

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

Che quella funzione sia scritta bene (a parte il [] al posto sbagliato :) ), su questo non ci piove. Che non sia bucabile non dipende *solo* da chi ha scritto quella funzione.
Come ha detto xeal, nella realtà difficilmente c'è una vulnerabilità nel caso specifico, ma quel codice compilato da un compilatore fallato *potrebbe* essere vulnerabile.
Il discorso è che *in potenza* anche quelle due righe di codice possono essere vulnerabili.

Se è per questo, anche la funzione più bacata dell'universo finchè non la compili e non la esegui è innocua :p

E appena la compili saltano fuori un paio di cose:

a) da sola non serve a niente, non può essere eseguita, quindi il compilatore dovrà aggiungere dei pezzi che possono essere "un po' meno innocui". Detto altrimenti, non è molto utile guardare alla singola istruzione, o a gruppi di istruzioni (puoi sostituire "return 0" con qualsiasi sequenza di codice esente da bug), o a singole funzioni, e dire questo è giusto è questo invece no, perchè non è questione di stabilire dove stia l'errore, quasi come se si dovesse trovare l'istruzione "colpevole", ma piuttosto bisogna considerare cosa accade quando tutti i pezzi sono messi insieme, perchè cisacuno, preso singolarmente, non serve a niente, ma quando sono messi insieme devono funzionare correttamente.

In questo senso, anche una funzione buggata, presa singolarmente, può essere "corretta", nella misura in cui fa esattamente quello che il programmatore voleva fare con la sequenza di input/output che aveva in mente: quando si programma qualcosa, a meno di avere una certa esperienza ed essere abituati a prevedere l'imprevedibile (e se programmi con i criteri del test driven developement ci riesci meglio), avrai comunque in mente una situazione specifica da riprodurre (nel nostro esempio, il non fare niente), e finchè si presenta quella precisa situazione (nel nostro esempio, possiamo pensare all'esecuzione del programma senza passare argomenti) non ci saranno problemi. I problemi però possono nascere nel momento in cui alla funzione vengono passati dei dati non previsti dal programmatore, ed ecco che può succedere qualcosa di sgradevole: seguendo la logica del "questo è innocuo" verrebbe da pensare che il problema risiede altrove, perchè da qualche altra parte sono stati preparati dei dati "sbagliati" da dare in pasto alla mia funzione, però la mia funzione non deve creare problemi anche quando elabora dei dati "sbagliati", quindi se in presenza di errori "esterni" va in crisi è comunque buggata anche la mia funzione.

b) Tu stai considerando in pratica solo quello che sta dentro le parentesi graffe, e cioè "return 0", e concludi che è innocuo, però la funzione semplicissima su cui stiamo discutendo fa anche altre cose, solo che non si vedono subito perchè le fa implicitamente: non mi riferisco solo a tutto ciò che sta attorno e che serve a creare un processo completo, ma alla funzione in sè, perchè nel dichiarare "int main(int argc, char **argv)" io sto dicendo che la funzione ha due variabili locali, argc e argv, e che queste variabili vanno inizializzate (formalmente le chiamiamo "parametri formali", ma in pratica sono delle vere e proprie variabili locali che vengono inizializzate scrivendoci qualcosa che viene preso altrove, quando cioè avviene la sostituzione dei "parametri attuali" ), ed è proprio questa inizializzazione, che comunque fa parte della funzione, che può creare problemi (anche se viene gestita, o può esserlo, in parte, da qualcosa di esterno: diciamo che il problema è a cavallo tra la funzione e il codice che la chiama, quindi il problema è di entrambi).

Se volessimo scrivere quella funzione in pseudocodice, guardando solo ciò che sta dentro, scriveremmo:

1. esci senza fare niente *

*in realtà fa qualcosa, ma ne parliamo tra un po'

quando invece l'intera funzione corrisponde a:

1. inizializza il primo parametro
2. inizializza il secondo parametro
3. esci senza fare niente

A questo punto si potrebbe obiettare: ma argc e argv sono rispettivamente un intero e un puntatore, quindi è praticamente impossibile che vengano sovrascritti con valori sbagliati. Soffermiamoci sul "praticamente": questo tipo di dati hanno una dimensione fissa e sono facili da gestire correttamente (anche se questo non esclude, in teoria, un errore), ma la suddetta dimensione, in linguaggi come il C, dipende dalla macchina, quindi un ipotetico compilatore bacato, che consenta di produrre codice per macchine diverse, può IN TEORIA fare dei pasticci, e questo in risposta ad un nostro preciso ordine espresso da "int main(int argc, char** argv)".

L'errore può avvenire ad opera del compilatore, ma anche del programmatore, ad esempio si potrebbe prevedere una direttiva per indicare il tipo di processore per cui si compila, per poi indicare male il codice del processore in una define (dove per male si intende o l'indicazione del codice sbagliato, oppure del codice giusto ma in un posto sbagliato, o di codici diversi in più posti, creando così confusione); in ogni caso, il risultato finale non cambia: TEORICAMENTE si rischia di sovrascrivere qualcosa che non si dovrebbe invece toccare (potrebbe anche accadere qualcosa di più subdolo, benchè forse meno probabile: un errore hw momentaneo corrompe alcuni dati in memoria e tra questi viene alterato il contenuto di una variabile usata dal compilatore per determinare la macchina target).

E a questo punto diventa molto meno innocuo anche il semplice "return 0", perchè non dice che la funzione deve terminare e basta, ma che deve ritornare il valore 0, il quale sarà scritto da qualche parte, quindi ci ritroviamo di nuovo con il rischio di un problema a cavallo tra quello che fa il nostro codice e quello che fa il sistema operativo, o più in generale il codice che sta attorno. E, sempre nel caso generale, gli eventuali errori da chi vanno gestiti/tenuti in conto in fase di programmazione, dal codice che faccio io o da quello che sta attorno e che fai tu? nel dubbio: da tutti e due.

Chiaramente, stiamo discutendo su di una situazione un po' estrema, però il fatto che si possa verificare con estrema difficoltà (nello specifico) non vuol dire che il rischio, ad un livello teorico, non sussista, anzi. Ma allora come faccio a sapere se il mio codice è "innocuo" oppure no? Semplice: NON POSSO! Non a priori, almeno. Quindi dovrò fare dei test approfonditi, nel limite dell'umanamente possibile, cercando di tener conto anche di certe sottigliezze, ma senza esagerare, perchà altrimenti mille anni non mi basterebbero... e allora mi fermo ad un livello ragionevole, confidando che certe questioni "basilari" vengano trattate adeguatamente ad un livello più basso di quella a cui opero io (= compilatore, sistema operativo, ecc.). In questo senso, quel semplicissimo main che "non fa niente" (ma abbiamo visto che non è vero: copia due valori esterni nelle sue variabili interne e copia il valore di ritorno in una variabile esterna) si può considerare ragionevolmente sicuro, ma non si può affermare che sia sicuramente esente da "difetti" ;)

Chiudendo con un cliché:

L'unico computer sicuro, è un computer spento!

:Prrr: