Corrado Giustozzi

INsicurezze/ L'insostenibile leggerezza del software

di C. Giustozzi - La scoperta di Heartbleed, uno dei bug pi¨ potenzialmente devastanti della storia, suscita riflessioni non solo sulla vulnerabilitÓ dei sistemi. Ma anche sui modelli di sviluppo del software "mission critical"

Roma - Il folklore dei programmatori annovera da decenni molteplici istanze specifiche della più generale legge di Murphy, le quali descrivono ironicamente ma non tanto i molteplici modi in cui la generale perversità della Natura si manifesta anche nello specifico settore dello sviluppo del software. Dice ad esempio la Seconda legge di Weinberg che "Se gli ingegneri costruissero gli edifici come i programmatori sviluppano i programmi, il primo picchio di passaggio raderebbe al suolo l'intera civiltà"; mentre il primo dei Postulati di Troutman afferma che "L'errore che produce il danno maggiore sarà scoperto solo dopo almeno sei mesi di uso del programma".

Ebbene, il famoso e famigerato bug denominato Heartbleed identificato nella libreria OpenSSL, che da alcuni giorni monopolizza l'attenzione persino dei media generalisti e dei quotidiani mainstream (i quali continuano a scriverne in modo grossolanamente impreciso, ma tant'è...), sembra confermare in pieno quanto presagito dalla saggezza della categoria sin da tempi davvero non sospetti. Esso infatti, se da un lato ha rischiato di mettere in ginocchio una parte significativa del sistema mondiale sul quale si basano la sicurezza e la riservatezza delle comunicazioni in Rete, minando alla base l'infrastruttura preposta alla garanzia sulle identità dei corrispondenti e l'inviolabilità delle comunicazioni, dall'altro è rimasto in circolazione, non ufficialmente scoperto, per oltre due anni dalla sua involontaria (o così almeno pare) introduzione nel codice di produzione. Peggio di così, insomma, non poteva andare.

Ma di cosa esattamente si tratta, e perché è così pericoloso? E, soprattutto: com'è potuto succedere? Proviamo a fare il punto della situazione.
Cos'è Heartbleed
Il bug denominato Heartbleed, formalmente identificato mediante il codice CVE-2014-0160 con cui è catalogato nel database Common Vulnerabilities and Exposures, tecnicamente non è altro che un classico e banale caso di "memory out of bound", ossia di accesso ad un'area di memoria indebita a causa di un indice inizializzato male ed in assenza di controlli specifici atti ad impedirlo. Un errore insidioso ma tra i più comuni, specie tra i programmatori principianti, favorito dal fatto che linguaggi come il C per motivi di efficienza non effettuano automaticamente a run-time il controllo del superamento dei limiti.

Nella fattispecie il bug venne introdotto all'interno della libreria OpenSSL nel lontano 2011 quando tale Robin Seggelmann, all'epoca dottorando all'Università di Duisburg-Essen in Germania, implementò la cosiddetta estensione Heartbeat nel protocollo SSL/TLS. Questa, che letteralmente significa "battito cardiaco", era stata proposta alla IETF (Internet Engineering Task Force) proprio da Seggelmann ed altri, e sarebbe stata da lì a poco emanata come standard formale di Internet col nome di "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension" (RFC 6520, febbraio 2012). Essa consiste essenzialmente in uno scambio continuo di speciali pacchetti fra client e server autenticati, allo scopo di mantenere attiva e verificata una sessione sicura senza dover rinegoziare ogni volta la connessione.

Il bug nel codice di Seggelmann si trova nella funzione invocata per costruire il pacchetto di Heartbeat da scambiarsi fra client e server, e consiste nel non verificare la validità del valore memorizzato in una variabile, usata come parametro, che dovrebbe contenere la lunghezza del pacchetto stesso. In pratica alla funzione vanno passati come parametri sia il contenuto da assegnare al pacchetto (sotto forma di un array di caratteri) che la lunghezza del pacchetto stesso, ma la mancanza di validazione fa sì che la lunghezza del pacchetto creata dalla funzione possa essere diversa, ed in particolare molto maggiore, di quella dell'array che ne costituirà il contenuto effettivo. Una dimenticanza apparentemente banale ma profondamente pericolosa, come vedremo tra un attimo.

Seggelmann inviò dunque il suo codice per revisione a Stephen N. Henson, uno dei quattro sviluppatori principali di OpenSSL, il quale apparentemente non notò il problema ed incluse il tutto nel repository dei sorgenti della libreria il 31 dicembre 2011. Il codice incriminato entrò quindi a far parte della versione ufficiale 1.0.1 di OpenSSL rilasciata pubblicamente il 14 marzo 2012, e subito adottata da un numero enorme di siti e di distribuzioni di sistemi operativi. Anche le successive release minori, fino alla 1.0.1f, contengono tutte il bug, il quale è stato corretto solo nella versione 1.0.1g rilasciata il 7 aprile 2014 in seguito alla scoperta del problema da parte di alcuni ricercatori indipendenti (Riku, Antti and Matti dell'azienda finlandese Codenomicon e Neel Mehta di Google Security). Per la cronaca, il nome Heartbleed (sanguinamento del cuore) con cui il problema è oggi noto era stato assegnato informalmente al bug dai ricercatori di Codenomicon come gioco di parole su Heartbeat (battito del cuore), ma è subito diventato il nome "ufficiale" con cui esso è universalmente identificato.

Chiarito qual è il bug, vediamo come sia possibile sfruttarlo per carpire informazioni ad un server vulnerabile. Purtroppo è molto facile: basta infatti semplicemente richiedere la restituzione di un pacchetto Heartbeat creato assegnando valori opportunamente malformati ai parametri che ne regolano la costruzione. In pratica occorre passare alla funzione una stringa di inizializzazione corta (ad esempio "pippo") ed un valore esageratamente ampio come descrizione della sua lunghezza (ad esempio 1.000 o più), ciò che corrisponde a chiedere al server di restituirci un pacchetto costituito dalla stringa "pippo" di mille caratteri! A questa richiesta apparentemente insensata e contraddittoria il server, in mancanza di una specifica validazione, non obietta ma reagisce stolidamente allocando in memoria un buffer di mille caratteri, copiandovi la stringa "pippo" e rimandando indietro tutti e mille i caratteri.

Otterremo così in risposta dal server un pacchetto di mille caratteri nel quale i primi cinque sono la striunga "pippo" e i rimanenti 995 caratteri contengono fedelmente i valori che erano contenuti nella particolare area di memoria del server nella quale è avvenuta l'allocazione del buffer!

In pratica con questo espediente riusciamo ad ottenere dal server la copia di una parte della sua memoria di lavoro, che può in realtà essere di ben 64K per volta; e, trattandosi di memoria dello spazio dati usato dall'istanza attiva del codice OpenSSL, è molto probabile che contenga informazioni significative per il processo stesso, quali ad esempio la chiave privata del server o le credenziali dei client utilizzate nelle sessioni aperte o comunque recenti. Nulla vieta inoltre di inviare centinaia o migliaia di richieste analoghe, per ricostruire così a colpi di 64K alla volta aree assai ampie della memoria del server ed aumentare le probabilità di trovarvi informazioni utili.

In pratica, a furia di richieste ripetute, un client malevolo può riuscire a mapparsi completamente o almeno in buona parte lo spazio di memoria logicamente allocato dal server al processo relativo all'istanza attiva di OpenSSL, di fatto rivelando in chiaro ogni e qualsiasi dato ad esso collegato: comprese quindi le chiavi private e/o le password degli utenti. Un "leakage" di proporzioni colossali, e soprattutto attuabile con facilità e senza lasciare alcuna traccia.

Prove realmente svolte da diversi ricercatori hanno confermato in modo evidente che, effettuando alcune migliaia di richieste, è effettivamente assai probabile riuscire ad ottenere password in chiaro ed altre informazioni critiche dall'analisi dei segmenti di memoria ottenuti. Il problema è infatti aggravato dal fatto che la libreria OpenSSL, per allocare memoria, non utilizza le classiche chiamate standard di sistema quali malloc(), ma implementa delle proprie routine, cosa che comporta due effetti collaterali sfavorevoli: il primo è che così facendo si massimizzano le probabilità che la memoria allocata sia stata precedentemente utilizzata dallo stesso processo, e contenga quindi informazioni sensibili per il suo funzionamento e soprattutto "fresche"; il secondo è che si vanificano gli effetti di eventuali azioni mitigatrici di "sanitarizzazione" della memoria svolte dagli allocatori di sistema, i quali non vengono affatto invocati.
443 Commenti alla Notizia INsicurezze/ L'insostenibile leggerezza del software
Ordina
  • Heartbleed, come piu' di qualcuno un paio di settimane fa ebbe modo di dire: "un bug dalle ripercussioni pratiche assolutamente irrilevanti"

    http://www.networkworld.com/news/2014/041714-tor-a...


    complimenti per l'oculatezza e la lungimiranza di quel qualcuno
    non+autenticato
  • - Scritto da: tucumpatch
    > Heartbleed, come piu' di qualcuno un paio
    > di settimane fa ebbe modo di dire: " un bug
    > dalle ripercussioni pratiche assolutamente
    > irrilevanti
    "
    >
    > http://www.networkworld.com/news/2014/041714-tor-a
    >
    >
    > complimenti per l'oculatezza e la lungimiranza di
    > quel
    > qualcuno

    Belink ?
    E chi mai ???
    non+autenticato
  • - Scritto da: tucumpatch
    > Heartbleed, come piu' di qualcuno un paio
    > di settimane fa ebbe modo di dire: " un bug
    > dalle ripercussioni pratiche assolutamente
    > irrilevanti
    "
    >
    > http://www.networkworld.com/news/2014/041714-tor-a
    >
    >
    > complimenti per l'oculatezza e la lungimiranza di
    > quel
    > qualcuno

    Già.
    Ricordiamo che sono i soliti cantinari che guardano ai cattivi Apple e Microsoft e non guardano a quel maledettissimo codice open di cui se ne vantano da anni e che FA DANNI immani.

    In galera.

    Subito.
    maxsix
    8721
  • Inizio lezioso, ma poi lettura piacevole.
    non+autenticato
  • http://support.apple.com/kb/HT6150
    li' vedo kg di heap/stack buffer overflow, memory corruption e (aiuto) out of bound error.
    MA NON PUO ESSERE perche' questo software e' scritto da programmatori seri, con il loro ciclo di revisione professionale e pagati da una multinazionale. (quindi il sito e' stato per forza violato e inquinato !)

    Ma c'e' di peggio : tra i package aggiornati con bug fix c'e' Apache, PHP e CURL.
    Ma e' software opensource!!! Cosa ci fa' nel repository Apple?
    Qui c'e' solo software scritto da programmatori seri, con il loro ciclo di revisione professionale e pagati da una multinazionale.
    (quindi il sito e' stato per forza violato e inquinato !)

    PEGGIO ANCORA! Guardate il bug di Curl .. NON verifica i certificati X.509 nel caso di HTTPS, se la negoziazione punta a un ip (e non ad un fqdn).
    bug che c'e' SOLO su osx, ed era stato segnalato a novembre 2013 e fixato solo ora! [*]
    E' IMPOSSIBILE che sia successo a programmatori seri, con il loro ciclo di revisione professionale e pagati da una multinazionale.
    (quindi il sito e' stato per forza violato e inquinato !)

    [*] https://gist.github.com/rmoriz/fb2b0a6a0ce10550ab7...
    non+autenticato
  • Mele con pere.

    Clicca per vedere le dimensioni originali
    non+autenticato
  • - Scritto da: sgabbio
    > Mele con pere.
    >
    > [img]http://www.publicdomainpictures.net/pictures/
    maddeche'. quello e' Mele con Maxsix, semmai (mele bacate of coz).

    Sta delirando da giorni (anni?) su opensource, bug, coder cantinari(?) VS la magnificenza dei coder professionisti pagati da un azienda privata (che fa sw closed 'certificato' dai suoi abili coder), ecc.
    Con un post da poche righe si smontano tutte le sue cacate.

    Bisogna leggerlo pero'Sorride
    non+autenticato
  • - Scritto da: bubba
    > http://support.apple.com/kb/HT6150
    >   li' vedo kg di heap/stack buffer overflow,
    > memory corruption e (aiuto) out of bound error.
    >

    Impugni il mouse con la mano sbagliata Arrabbiato
    Izio01
    3808
  • - Scritto da: bubba
    > Ma c'e' di peggio : tra i package aggiornati con
    > bug fix c'e' Apache, PHP e
    > CURL.
    >   Ma e' software opensource!!!

    Software open source buggato? Parbleu, mai sentita una cosa simile!
    ruppolo
    33147
  • - Scritto da: ruppolo
    > - Scritto da: bubba
    > > Ma c'e' di peggio : tra i package aggiornati
    > con
    > > bug fix c'e' Apache, PHP e
    > > CURL.
    > >   Ma e' software opensource!!!
    >
    > Software open source buggato? Parbleu, mai
    > sentita una cosa
    > simile!
    vedo che non sai leggere! non e' "semplice" software opensource dei cantinari linuxiani... e' Software updates for OS X ! Apple ! seri professionisti pagati dalla multinazionale che mai userebbe roba per cantinari! men che meno ficcherebbe dei bug propri in curl!

    O NO?A bocca aperta
    non+autenticato
  • - Scritto da: bubba
    > - Scritto da: ruppolo
    > > - Scritto da: bubba
    > > > Ma c'e' di peggio : tra i package
    > aggiornati
    > > con
    > > > bug fix c'e' Apache, PHP e
    > > > CURL.
    > > >   Ma e' software opensource!!!
    > >
    > > Software open source buggato? Parbleu, mai
    > > sentita una cosa
    > > simile!
    > vedo che non sai leggere! non e' "semplice"
    > software opensource dei cantinari linuxiani... e'
    > Software updates for OS X ! Apple !

    Certo, per la parte dei cantinari linuxiani.

    > seri professionisti pagati dalla multinazionale
    > che mai userebbe roba per cantinari ! men
    > che meno ficcherebbe dei bug propri in curl!
    >
    >
    > O NO?A bocca aperta

    Infatti ecco il conto per aver usato la roba dei cantinariA bocca aperta
    ruppolo
    33147
  • - Scritto da: ruppolo

    > Infatti ecco il conto per aver usato la roba dei
    > cantinari
    >A bocca aperta

    disse il tipo la cui azienda del cuore usa al 90% software BSD Rotola dal ridere
    non+autenticato
  • - Scritto da: bubba
    > http://support.apple.com/kb/HT6150
    >   li' vedo kg di heap/stack buffer overflow,
    > memory corruption e (aiuto) out of bound error.
    >
    Tu come gli altri non vedi proprio niente perché:

    For the protection of our customers, Apple does not disclose, discuss, or confirm security issues until a full investigation has occurred and any necessary patches or releases are available. To learn more about Apple Product Security, see the Apple Product Security website.

    Inoltre guarda cosa mi è arrivata questa mattina:

    With recent news of the Heartbleed bug and its associated vulnerability in the OpenSSL library, here is what you need to know about how it affects Zend Server:

    On Linux systems, Zend Server uses the OpenSSL library provided by the operating system. Zend Server does not need to be updated, but please ensure your Linux system is properly updated so all services using OpenSSL (including Zend Server as well as potentially many others) are secure. If you have been using a vulnerable version of OpenSSL (1.0.1 through 1.0.1f inclusive) we highly recommend updating your security keys and passwords after updating the library.
    On Windows, IBM i, and Mac OS X systems Zend Server uses OpenSSL 0.9.8, which is unaffected by this vulnerability.

    E sottolineo per tutti gli ascoltatori, non vedenti:
    QUESTA MATTINA

    Sparite, fate più bella figura.
    maxsix
    8721
  • - Scritto da: maxsix

    > For the protection of our customers, Apple does
    > not disclose, discuss, or confirm security issues
    > until a full investigation has occurred and any
    > necessary patches or releases are available. To
    > learn more about Apple Product Security, see the
    > Apple Product Security
    > website.

    in pratica possono nascondere la verità per anni

    > E sottolineo per tutti gli ascoltatori, non
    > vedenti:
    > QUESTA MATTINA

    e quindi? Zend Server non è vulnerabile e hanno dovuto fare le opportune indagini per verificarlo

    sai com'è, lavorare richiede tempo, mica c'abbiamo la bacchetta magica

    ma l'importante è avere un OS che sforna una media di 90 vulnerabilità all'anno Rotola dal ridere
    non+autenticato
  • ...i bachi esistono e il modello opensource non garantisce (per forza) maggiore sicurezza. Potenzialmente c'e' la predisposizione per il proverbiale "tutti posso leggere il codice", ma come e' successo in questo caso molti non hanno capito il potenziale problema insito nell'heartbit (il team di freebsd se non sbaglio, l'aveva capito e non l'ha mai compilato) e nemmeno nel baco segnalato dallo stesso autore di questo. Detto questo, quello che mi sconcerta abbastanza, e' che molte delle aziende che usavano questa libreria "critica", se ne sono bellamente battuti le p*lle di controllare la libreria prima di usarla. Io trovo questo comportamento assurdo.
    Secondo la mia opinione il problema maggiore in tutta questa storia e' che molte aziende vedono nell'opensource un buon modo di avere software gratis senza investire un minimo in sviluppo e ricerca, per poi avere ricavi massimi (per altro non contribuendo un minimo al modello stesso e magari riempiendosene la bocca a caz*o). Poi, tutta la polemica sterile (portata avanti anche da questo articolo) che un paradigma sia piu' o meno sicuro di un altro lascia veramente il tempo che trova, con buona pace dei tifosi delle varie controparti.
    non+autenticato
  • Questo è il vero punto del discorso, le aziendone si sono preoccupate solo del lucro, degli utenti "non gli è importato na pizza". Usare a man bassa, contribuire... ma che scherzi?
    non+autenticato
  • - Scritto da: Ogekury

    > da questo articolo) che un paradigma sia piu' o
    > meno sicuro di un altro lascia veramente il tempo
    > che trova, con buona pace dei tifosi delle varie
    > controparti.

    però l'affermazione che hai fatto su FreeBSD contraddice quanto scrivi

    se openssl non fosse stata opensource, i signori di freebsd non avrebbero mai saputo quale fosse la strada più sicura da intraprendere

    quando si parla di open e sicurezza, si parla di sicurezza potenziale, ma se l'utilizzatore è un sempliciotto approssimativo, non c'è open che tenga

    nel caso closed, invece, il fatto che il software sia visibile da una sola entità, rende il tutto dipendente dalle attitudini di tale entità (per esempio, ms è famosa per essersene sbattuta di bug e vulnerabilità, fino a che non è comparsa la competizione e internet ha esacerbato il problema del malware )
    non+autenticato
  • - Scritto da: collione
    > - Scritto da: Ogekury
    >
    > > da questo articolo) che un paradigma sia
    > piu'
    > o
    > > meno sicuro di un altro lascia veramente il
    > tempo
    > > che trova, con buona pace dei tifosi delle
    > varie
    > > controparti.
    >
    > però l'affermazione che hai fatto su FreeBSD
    > contraddice quanto
    > scrivi
    >
    > se openssl non fosse stata opensource, i signori
    > di freebsd non avrebbero mai saputo quale fosse
    > la strada più sicura da
    > intraprendere
    >
    > quando si parla di open e sicurezza, si parla di
    > sicurezza potenziale, ma se l'utilizzatore è un
    > sempliciotto approssimativo, non c'è open che
    > tenga
    >
    > nel caso closed, invece, il fatto che il software
    > sia visibile da una sola entità, rende il tutto
    > dipendente dalle attitudini di tale entità (per
    > esempio, ms è famosa per essersene sbattuta di
    > bug e vulnerabilità, fino a che non è comparsa la
    > competizione e internet ha esacerbato il problema
    > del malware
    > )
    L'ho scritto all'inizio che e' potenzialmente piu' sicuro (ma non necessariamente) e il caso di FreeBSD lo dimostra (l'utilizzo di memoria dell'heartbit era in effetti avventato). Non ho espresso mi sembra, alcuna contraddizione, ho solo sostenuto che le disamine sul paradigma piu' sicuro sono, a mio parere, fuorvianti e strumentalizzate dai vari tifosi del caso
    non+autenticato
  • non vedo perchè sarebbero fuorvianti

    si prendono tot software open, tot software closed e si vede chi ha più vulnerabilità

    Coverity fa questo di mestiere, e dice che l'open presenta una migliore sicurezza

    ovviamente i casi particolari sono appunto particolari
    non+autenticato
  • - Scritto da: collione
    > non vedo perchè sarebbero fuorvianti
    >
    > si prendono tot software open, tot software
    > closed e si vede chi ha più
    > vulnerabilità
    >
    > Coverity fa questo di mestiere, e dice che l'open
    > presenta una migliore
    > sicurezza
    >
    > ovviamente i casi particolari sono appunto
    > particolari
    A quello mi riferivo, al fatto che non si puo' essere sicuri che il software sia piu' sicuro solo perche' il sistema in cui e' fatto presuppone piu' sicurezza. Esistono sempre le eccezioni come nel caso di questa librearia, in cui la code review non ha funzionato (o piu' probabilmente non e' stata fatta). Poi ancora, sono convinto che come paradigma quello dell'open sia "a rigor di logica" piu' sicuro
    non+autenticato
  • - Scritto da: ogekury

    > A quello mi riferivo, al fatto che non si puo'
    > essere sicuri che il software sia piu' sicuro
    > solo perche' il sistema in cui e' fatto
    > presuppone piu' sicurezza. Esistono sempre le

    loro non stanno supponendo, ma analizzando un tot di progetti open e confrontando i risultati con un tot di progetti closed

    > probabilmente non e' stata fatta). Poi ancora,
    > sono convinto che come paradigma quello dell'open
    > sia "a rigor di logica" piu'
    > sicuro

    appunto, loro si riferiscono al modello opensource, ma ovviamente ogni gruppo di sviluppatori può fare tutte le cazzate che vuole, anche operando secondo il modello open

    e non è un caso che i software BSD e similari siano i più colpiti, perchè si tratta di licenze che non invogliano la partecipazione, soprattutto da parte delle aziende
    non+autenticato
  • Un colpo al cerchio...
    I fatti, come sempre mi danno ragione! Quante volte ve l'ho detto che linux è un sistema operativo per gli studenti universitari, al livello si e no di windows 95? Occhiolino
    Adesso CHI È CHE AVEVA RAGIONE?Arrabbiato EH?Arrabbiato Eh? Arrabbiato
    Le voglio proprio vedere le facce di quelli che criticavano Windows 8 di Microsoft Corporation (TM). Che c'è? Vi si è seccata la lingua?

    Ed uno alla botte...
    Ma vogliamo parlare dei macachi? Indiavolato Quelli che di open c'hanno addirittura il kernel di OSX ma si danno tante arie da closed? Siete la vergogna del (C), del (TM) e dell' (O) messi assieme! Peracottari dell'informatica! Rotola dal ridereRotola dal ridereRotola dal ridere

    Meno male che io uso ClosedSSL della Microsoft Corporation (TM) che essendo closed source è sicura perché l'ha controllata Padella! Eh eh!Rotola dal ridere

    Parola di Winaro!Occhiolino
    non+autenticato
  • - Scritto da: Winaro
    > Un colpo al cerchio...
    > I fatti, come sempre mi danno ragione! Quante
    > volte ve l'ho detto che linux è un sistema
    > operativo per gli studenti universitari, al
    > livello si e no di windows 95?
    >Occhiolino
    > Adesso CHI È CHE AVEVA RAGIONE?Arrabbiato EH?Arrabbiato
    > Eh?
    >Arrabbiato
    > Le voglio proprio vedere le facce di quelli che
    > criticavano Windows 8 di Microsoft Corporation
    > (TM). Che c'è? Vi si è seccata la
    > lingua?
    >
    > Ed uno alla botte...
    > Ma vogliamo parlare dei macachi? Indiavolato Quelli che
    > di open c'hanno addirittura il kernel di OSX ma
    > si danno tante arie da closed? Siete la vergogna
    > del (C), del (TM) e dell' (O) messi assieme!
    > Peracottari dell'informatica!
    > Rotola dal ridereRotola dal ridereRotola dal ridere
    >
    > Meno male che io uso ClosedSSL della Microsoft
    > Corporation (TM) che essendo closed source è
    > sicura perché l'ha controllata Padella! Eh
    > eh!Rotola dal ridere
    >
    > Parola di Winaro!Occhiolino

    Il dito e la luna.

    Clicca per vedere le dimensioni originali
    non+autenticato
  • perchè posti boiate, figliolo?
    non+autenticato
  • > Ed uno alla botte...
    > Ma vogliamo parlare dei macachi? Indiavolato Quelli che
    > di open c'hanno addirittura il kernel di OSX ma
    > si danno tante arie da closed? Siete la vergogna
    > del (C), del (TM) e dell' (O) messi assieme!
    > Peracottari dell'informatica!
    > Rotola dal ridereRotola dal ridereRotola dal ridere
    Da incorniciare Rotola dal ridere
    non+autenticato
  • Io capisco le cose solo quando me le spiega winaro.
    È l'unico, in questa massa di trolloni, che ti fa vedere veramente chiaroA bocca aperta
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | 4 | Successiva
(pagina 1/4 - 20 discussioni)