Tango Down

L'expression est la mode. La victime du jour: Skype.

Sur le blog de Skype, on peut lire:

Under normal circumstances, there are a large number of supernodes available. Unfortunately, today, many of them were taken offline by a problem affecting some versions of Skype. As Skype relies on being able to maintain contact with supernodes, it may appear offline for some of you.

Je ne peux m'empecher de repenser aux presentations de Serpi, Phil et compagnie sur le sujet, evoquant la possibilite de DoS-er le reseau Skype en envoyant aux super-noeuds la commande de desactivation.

Maintenant les techniciens de Skype s'activent a creer de nouveaux mega super-noeuds pour retablir le reseau. C'est moche.

Overflow du serveur FTP de IIS 7.5

Comme cadeau de Noel cette annee, Microsoft a decide de nous offrir un overflow distant pre-authentification dans le service FTP de IIS 7.5 (Windows 7 et 2008 R2). Le bug est marrant. Considerons l'extrait de pseudo code C suivant:

char *src,*dst,*end;
...
while (src!=end) {
if (*(++src)==(char)0xff)
    *(dst++)=(char)0xff;
*(dst++)=*src;
}

Evidemment, si dst a assez de place pour accomoder les caracteres 0xff supplementaires, tout se passe bien. Le probleme se situe dans un cas particulier ou si la taille de src plus le nombre de 0xff est inferieure ou egale a la taille du buffer courant, alors pas la peine d'allouer dst, et on se contentera de dst=src. Dans ce cas precis, si src contient deux caracteres 0xff (ou plus, et pas necessairement consecutifs), dst va commencer a ecrire des 0xff dans une portion de src pas encore lu. Le nombre de 0xff dans src n'est alors plus deux, mais trois, et ca continue a augmenter. Au final, on va deborder de dst avec plein de 0xff.

La simple chaine '\xff\xff\xff\xff'+'A'*0x200+'\r\n' fera planter le service FTP d'IIS.

Le bug est-t-il exploitable? C'est loin d'etre gagne. La taille allouee pour src est controlable, la taille du debordement est controlable, le contenu ... pas super controlable. Il se peut qu'il soit possible de faire quelque chose avec le contenu d'un chunk ecrase par une serie de 0xff avant que le processus ne parte en vrille. Ou pas.

Maintenant concernant la terminologie: un debordement de buffer peut aboutir a un deni de service s'il n'est pas correctement exploite, les deux termes ne sont pas exclusifs.

La dette publique Americaine

http://en.wikipedia.org/wiki/United_States_public_debt:

Leading Foreign owners of US Treasury Securities (July 2010)
Nation/Territory	billions of dollars	percentage
People's Republic of China (mainland)	846.7	20.8
Japan	821.0	20.2

Sur Marin

Un sous-marin nucléaire d'attaque britannique s'échoue en Ecosse



C'est beau la technologie.

"Cyber guerre", 42e edition, et fichiers MOF

Ces derniers deux derniers jours, les medias americains grand public (a savoir les journaux televises que je regarde) ont consacre une part non negligeable de leurs efforts journalistiques a Stuxnet. La raison: le NY Times donne la paternite du ver aux Israeliens (ou pas du tout si on lit l'article). L'attrait du commun des mortels pour les histoires d'espionnage fait le reste. Trois jours plus tot on trouvait une information similaire sur des blogs eclaires. Sur Le Monde, l'hypothese de l'operation marketing surgit aussi.

Meme si je n'ai pas d'information sur l'instigateur de l'operation, je peux cependant offrir quelques details techniques sur l'aspect exploitation du ver. Nicolas a passe cette derniere semaine a jouer avec Stuxnet, et a extrait et reecrit les deux 0days restant, non encore publies (disponibles aux clients Early Update de CANVAS). Des details sur ces vulnerabilites sont publics, le 1er utilise un fichier de "keyboard layout" specialement concu pour aboutir a l'execution de code en Ring0 sous Windows 2000 et XP, le 2nd utilise une vulnerabilite du "Task Scheduler" sous Vista et 7 pour elever les privileges d'un utilisateur local. Ajoutons a cela un faux 0day du Spooler d'impresssion de Windows, et celui des fichiers .LNK, et nous obtenons un bon cyber arsenal au format .exe. C'est d'autant plus beau que les auteurs de Stuxnet l'ont lache dans la nature, reduisant considerablement la duree de vie potentielle de leurs 0days. C'est culote, mais le jeu devait en valoir la chandelle.

Dans un post precedent, j'evoquais un moyen d'executer du code en deposant un fichier dans un repertoire privilegie de Windows. Lors de l'ecriture de l'exploit MS10-061, je ne savais pas quelle technique utilisait Stuxnet - une lecture posterieure des divers documents disponibles m'apprendra que nous utilisons la meme: les fichiers MOF. Le "Managed Object Format" est documente sur le MSDN, et permet entre autres d'instrumenter WMI. Usuellement, pour executer un MOF, un utilisateur devra faire appel a mofcomp.exe. Cependant Windows offre une fonctionalite interessante: un sous repertoire de system32 est surveille, et tout fichier depose dedans sera automatiquement compile (system32\wbem\mof). Un des avantages de MOF est la possibilite d'y inclure du VBscript, et d'executer le dit script en tant que LOCALSYSTEM. Differents exemples de fichiers MOF peuvent etre recuperes sur le MSDN. On melange le tout, et on obtient la transformation d'une primitive d'ecriture de fichier dans un repertoire privilegie en execution de code immediate.

C'est beau la cyber guerre.

MS10-068: indice a 1, mais pas vraiment?

Apres en avoir plus ou moins fini avec la vulnerabilite du Spooler de Windows, je me suis attaque a celle de LSASS/AD, MS10-068. En regardant le resume des bulletins de Septembre, on peut voir que cette vulnerabilite a ete credite d'un indice d'exploitabilite de 1. Lorsque l'on regarde la FAQ du bulletin on peut lire:

Most attempts to exploit this vulnerability will cause an affected system to stop responding and restart.

Ca sonne plus comme une exploitabilite de 2+. Une analyze differentielle de ntdsa.dll montre plusieurs fonctions modifiees, dont 2 semblent correspondre a la description de la faille donnee dans le bulletin (encore une fois, peut-etre ne faut-il pas s'y fier): LDAP_REQUEST::GetSealHeaderField et LDAP_REQUEST::DecryptSignedOrSealedMessage. Il faut effectivement etre authentifie pour pouvoir sceller un message LDAP (une sorte de chiffrement MS qui se base sur une clee derivee de la negotiation NTLM). Le correctif est simple pour ces fonctions: verifier que le champ longueur du buffer SASL ne deborde pas lorsqu'on lui ajoute 4.

Un test avec une longueur de 0xfffffffc entraine une corruption du tas, et une violation d'acces en lecture lorsque la fonction de dechiffrement en atteint la fin. Cela merite plus de recherches, mais a premiere vue, je ne suis pas persuade que ce soit tres exploitable.

Stuxnet et ses quatre 0days

Je n'ai personnellement pas regarde Stuxnet, je me contente de reporter le nombre tel qu'on a pu le voir sur certains sites. Outre les fichiers .lnk qui ont fait coule de l'encre le mois dernier, on apprend ce mois ci que Stuxnet exploitait aussi une vulnerabilite 0day du Spooler de Windows pour se propager sur le reseau (local?). Un article du blog de Kaspersky illustre cela. Quatre 0days, backdoor industrielle, ca ne deconne plus. Quelqu'un (je prends les paris quant au gouvernement concerne) a du perdre beaucoup lorsque son petit prodige a ete porte a l'attention du public.

J'ai pu travailler ces deux derniers jours sur MS10-061, et bien que la vulnerabilite soit relativement simple, elle n'en est pas moins efficace. Etant donne un acces a une imprimante partagee (soit anonymenent, soit via un compte Guest ou des imprimantes antediluviennes), il est possible d'entrainer la creation arbitraire d'un fichier sur le disque systeme en tant qu'utilisateur privilegie. Il est aussi possible d'en maitriser le contenu. Maintenant la problematique d'ou et quoi ecrire se pose. Comment obtenir execution de code (ou d'une commande shell) de facon quasi immediate en deposant un fichier, tout en faisant preuvre d'un tant soit peu de finesse (eviter de remplacer un executable ou une bibliotheque)? L'immediatete recherchee exclut l'utilisation des repertoires lies au demarage de l'OS (bien que cela reste une solution valable pour le long terme).

En cherchant a droite et a gauche, je suis tombe sur le Task Scheduler de Windows. Chose que je ne savais pas, il est possible de deposer des fichiers .job directement dans %WINDIR%\Tasks, et ils seront pris en compte par le service de CRON de Windows. Le format des fichiers .job est definit dans le MSDN. J'ai tente de deposer des fichiers crees par mes soins (mais non signes) via la vulnerabilite Spooler, et l'execution a toujours echoue (probleme de droits d'acces que je n'ai pas pu resoudre dans le fenetre temporelle impartie). Un petit soucis de synchronisation se pose aussi.

La solution retenue pour l'exploit CANVAS utilise un autre format de fichier, a un autre endroit, et j'en dois la connaissance a Sinan - plus d'information sans doute plus tard. Je ne sais pas quelle technique Stuxnet utilise pour cet exploit, toujours est-il que ce ver place la barre assez haut en terme de technologie offensive.

Skillz

Les mecs auraient du choisir un autre metier...

Et un 42e bug dans xxxCreateWindowEx

Celui merite le detour dans la mesure ou il etait connu depuis 2007:

http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/57c3783b-dd38-4a57-9217-61a920541ad0

En retournant un pseudo handle HWND_TOPMOST dans le champ hwndInsertAfter d'un hook WH_CBT, on aboutit a une violation d'acces, exploitable si l'on mappe l'espace a NULL (difficilement, mais Ronald a fait quelque chose de plus ou moins stable).

Les personnes susceptibles de Googler "windows bluescreen" auront eu un local 0day pendant 3 ans 1/2. Malheureusement, Core Security l'a tue(r), et a ete credite a la place de "JonnyDeep" qui a fait l'effort de le reporter mais n'a pas ete ecoute par MS (ils devraient lire leurs propres forums de temps en temps!).

C'est dingue ce que l'on trouve sur le Windows Developer Center :)

Edit: Et aussi, contrairement a la precedente, la vulnerabilite n'est pas specifiee comme ayant ete connue du public. Duree de vie: 1301 jours (pour ceux qui veulent faire des slides sur les 0days).

"It does on CSI: Miami"

MS10-032, ou pourquoi c'est mal de changer de parent lors de la creation d'un enfant

Dans le bulletin MS10-032, trois vulnerabilites ont ete corrigees: CVE-2010-0485, CVE-2010-0484, CVE-2010-1255. Mais seule la premiere a un indice d'exploitabilite de 1. Il est interessant de constater que personne n'est credite pour la decouverte de cette vulnerabilite, decrite comme etant "Win32k Window Creation vulnerability". De plus, le bulletin specifie que la vulnerabilite a ete portee a la connaissance du public, mais il n'y a pas d'exploit circulant. Etrange.

Une rapide analyse differentielle du binaire (win32k.sys) mettra en evidence le rajout d'un "UnlinkWindow" dans une branche du code qui n'est atteinte que si WM_NCCREATE rate. Les fonctions "LinkWindow" et "UnlinkWindow" sont utilisees pour lier parents et enfants entre eux, pour la transmission de messages, le "Z-ordering", etc. Cependant, la liaison d'un enfant fraichement cree avec son parent n'a lieu qu'apres un WM_NCCREATE ayant reussi. Quel est donc l'interet de de-lier un enfant dont la creation a echoue, a un parent qu'il n'a pas? Tout simplement parceque dans le gestionnaire de WM_NCCREATE, il est possible de faire appel a SetParent() et donc de changer le parent d'un enfant en cours de creation.

Faire appel a SetParent() dans le gestionnaire de WM_NCCREATE et retourner 0, entrainera un cas singulier ou le parent pense qu'il a un enfant mais l'enfant a en fait ete detruit par un xxxFreeWindow(). Certains penseront de suite a un cas d'utilisation apres liberation, mais c'est en fait un chouillat plus complique. Le lien qui existe fait que lors de sa destruction, l'enfant est marque comme detruit mais pas libere. C'est moche, ca nous aurait facilite la tache. On se retrouve alors avec un enfant invisble, marque comme detruit, et qui ne repond a aucun message. Seule specificite de l'enfant, son parent est NULL. Il n'est pas facile de referencer le parent d'un enfant qui n'accepte aucun message. Il faut donc trouver un message a envoyer au parent, qui va etre diffuse a ses enfants, dont le traitement devra entrainer un referencement du parent. Il s'avere que deplacer le parent mettra en branle cette chaine d'evenements et se terminera en ecran bleu.

Quelques commentaires. Je pense que j'ai du rater quelque chose, parceque l'exploitation du chemin que j'ai trouve ne merite clairement pas un "1", c'est plus un 1.5 - 2. Certes on dipose de toutes les informations necessaires localement, mais la primitive que l'on obtient, une addition dans une boucle qui va finir par crasher, est difficilement exploitable. Je reviens maintenant sur le fait que cette vulnerabilite etait connue du public. Il faut remonter jusqu'en 2004 pour trouver une trace de ce bug:

http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2004-03/0602.html

microsoft.public.win32.programmer.kernel n'etait probablement pas le bon endroit pour signaler une faille de securite. Neanmoins certaines personnes attentives auront pu beneficier d'une elevation de privileges dans TOUTES les versions de Windows pendant ces 6 dernieres annees...

Edit: Un lien envoye par ivanlef0u sur un doc de taviso sur les parents des fenetres: https://docs.google.com/View?id=dfqd62nk_228h28szgz. Interessant!

Question du Jour

Trouve dans une DLL d'un systeme d'exploitation bien connu:

lea eax, [ebp+var_44] push eax ; hMem call ds:__imp__LocalFree@4 ; LocalFree(x)

Quelqu'un peut-il me dire:

1. Pourquoi c'est "mal"?
2. Quelle est l'erreur du programmeur qui a mene a ce code?
3. Comment exploiter cela?

Par une operation du Saint Esprit, le code n'est pas atteignable dans la DLL en question. C'est moche.

Exception Culturelle

La derniere fois que je suis tombe sur du code promouvant l'exception culturelle Francaise, il s'agissait de cles DES specifiees en dur dans le Protected Storage. Cette fois-ci, on va regarder SChannel.

Un utilisateur averti pourra se demander pourquoi dans SChannel v5.1.2600.5834 (XP SP3 US plus ou moins a jour) on trouve la fonction IsSchEncryptionPermitted(), qui contient:

call ds:__imp__GetSystemDefaultLCID@0 ; GetSystemDefaultLCID() cmp ax, 40Ch jz short loc_767F41A7 push 0Ah ; cchData lea ecx, [ebp+LCData] push ecx ; lpLCData push 5 ; LCType push eax ; Locale call ds:__imp__GetLocaleInfoA@16 ; GetLocaleInfoA(x,x,x,x) test eax, eax jz short loc_767F41A7 lea eax, [ebp+LCData] push eax call _MyStrToL@4 ; MyStrToL(x) cmp eax, 21h jnz short loc_767F41B8 loc_767F41A7: ; CODE XREF: IsSchEncryptionPermitted()+1Aj ; IsSchEncryptionPermitted()+2Dj  and _g_ProtEnabled, 0FFFFFFFCh mov _g_fFranceLocale, 1

Sauf que cette fois ci, le resultat n'est pas le meme. Si le Windows est francophone, on enleve les deux bits de poids faible de _g_ProtEnabled et on met a 1 une variable obscure.

Dans le code de SslReadRegOptions(), si _g_fFranceLocale est non 0, on ne prend pas en compte l'activation ou desactivation des protocoles specifies dans la base de registre, decrit dans la KB187498, si les bits de poids faible sont presents.

Les bits utilises pour l'activation des protocoles sont:

• "Multi-Protocol Unified Hello\\Client": 80000000h
• "Multi-Protocol Unified Hello\\Server": 40000000h
• "PCT 1.0\\Client": 2
• "PCT 1.0\\Server": 1
• "SSL 2.0\\Client": 8
• "SSL 2.0\\Server": 4
• "SSL 3.0\\Client": 20h
• "SSL 3.0\\Server": 10h
• "TLS 1.0\\Client": 80h
• "TLS 1.0\\Server": 40h

En conclusion, si je ne me suis pas plante, pas de drame - a part qu'un Windows francophone ne puisse pas faire de PCT du tout (client ou serveur). Ca m'aurait ete utile de savoir ca en 2004 pour l'exploit PCT Handshake...

Si quelqu'un veut confirmer, amusez-vous, je testerai sans doute dans la semaine pour verifier et mettrai a jour le post. Je n'ai pas d'explication au bannissement de PCT en France.

Et joyeux anniversaire a ma soeur!

Exploiter un double free() sous Windows

Un soir, une discussion avec Ronald et Sean nous a mene sur le sujet des doubles free() sous Unix, et je me suis rendu compte que je n'avais jamais exploite un double free() sous Windows. Bien que la problematique ne soit pas extremement complexe, il semblerait qu'il n'y ait pas des masses de documentation sur le sujet, a part une entree de sh0ck qui se retrouve massacree un peu partout.

Bien entendu, de nombreux elements entrent en compte:

• Y a-t-il ecriture des donnees entrent les deux free()?
• Le Heap en question a-t-il un Lookaside?
• Est-ce que le Lookaside a atteint sa profondeur maximale avant le 1er free()? Apres?
• Le Chunk libere est-il VirtualAllloc()'ed?

Quelques inexactitudes sur le sujet:

Tout d'abord: le free() d'un chunk deja marque comme libere (Chunk.Flag & 1 == 0) n'a aucun effet. Donc contrairement a ce qu'affirment des papiers comme Towards Automatically Generating Double-Free Vulnerability Signatures Using Petri Nets (1), meme s'il y a possibilite d'ecriture dans la partie data du chunk entre les deux free(), il ne se passera rien. S'il y a liberation, ecriture puis allocation, c'est une histoire differente (unlink sur un LIST_ENTRY maitrise qui donne un Write4) et ce n'est pas un double free().

Ensuite, si le chunk est VirtualAlloc'ed() - c'est usuellement le cas si la taille/8 est > 0xfe00 qui est le seuil par defaut - le 1er free() va retourner la page au gestionnaire de memoire de Windows qui va decommit la zone rapidement. Cela entrainera une violation d'acces lors du second free().

Nous sommes donc restreints aux cas ou le chunk est libere vers la Lookaside puisque dans ce cas la le chunk est toujours marque comme occupe. Donc:

1. Le Heap en question doit avoir un Lookaside
2. Le free() doit etre sur un chunk dont la taille est < 1024
3. L'entree correspondante du Lookaside doit avoir au moins 1 place disponible (la profondeur par defaut est 4 la plupart du temps) sinon il sera libere vers la FreeList[]

Apres, il existe plusieurs possibilites, que l'on trouvera decrites dans une entree du blog de Symantec par Matt Connover.

• Premier free() vers le Lookaside qui se retrouve plein entrainera un second free dans la FreeList[] (et potentiel coallesce) avec ecrasement du LIST_ENTRY apres premiere allocation, et une entree de Lookaside pointant vers le chunk libre (de la FreeList[]) suivant.
• Premier et second free() vers le Lookaside, qui entrainera une primitive WriteN lors de la troisieme allocation d'un chunk de la taille en question.

Au final, un double free() ca s'exploite relativement bien dans XP et 2003, mais pas comme le decrivent certains.

Edit: petite correction dans le 1er cas.

(1): "After it has been freed, the programmer mistakenly uses temp and writes X in the first 4 bytes and Y in the second 4 bytes of temp. Then the programmer frees temp again. The system will then try to insert temp into the free list for a second time right before where it is already inserted."

Supernaturel

Ce soir, Sam & Dean rencontrent le 3e Cavalier de l'Apocalypse: Mort. Cela faisait un moment que je n'avais pas autant accroche a une serie TV - mais Supernatural semble combler le manque. Voici le trailer de l'episode en attendant la diffusion dans une heure!

Microsoft et les bugs

Au hasard de mes peregrinations au sein de Windows j'ai ete confronte a une situation qui m'a laisse songeur. N'ayant pas tous les elements en main, si quelqu'un en sait davantage, n'hesitez pas a me corriger.

Dans des extensions FrontPage pour IIS 6, se trouve un morceau de code parsant les images GIF. Jusque la rien d'extraordinaire. Un rapide coup d'oeil aux symboles et l'on trouve les fonctions suivantes:

• VgdImageGifDecoder::Decode
• ReadOK
• VgdImageGifDecoder::LWZReadByte
• VgdImageGifDecoder::ReadColorMap
• VgdImageGifDecoder::DoExtension
• etc.

Un peu de Googling m'apprendra que LWZReadByte() est aussi present dans libgd et SDL_image. Au vu du nom des fonctions, on pourra supposer que Microsoft a pris le code de libgd pour decoder ses GIF. L'analyze du code assembleur revele du moins que les codes ont une source similaire.

Toujours est-il qu'une vulnerabilite a ete decouverte dans LWZReadByte il y a un moment, et a touche aussi bien libgd que SDL_image:

• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4484 pour libgd
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6697 pour SDL_image
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1373 pour un bug similaire dans CUPS, bien que la fonction ne soit pas la meme

Le code original semble provenir de 1990 par un certain David Koblas, mais je n'ai pas trouve de signalement du bug datant d'avant 2006.

Maintenant, regardons le code present dans Windows 2003 SP0 (sorti le 24 Avril 2003 d'apres Wikipedia):

.text:32E274FF ; private: int __thiscall VgdImageGifDecoder::LWZReadByte(class Vistream *, int, int) .text:32E274FF ?LWZReadByte@VgdImageGifDecoder@@AAEHPAVVistream@@HH@Z proc near .text:32E274FF ; CODE XREF: VgdImageGifDecoder::ReadImage(VgdImage *,Vistream *,int,int,uchar (*)[256],int,int)+8Ep .text:32E274FF ; VgdImageGifDecoder::ReadImage(VgdImage *,Vistream *,int,int,uchar (*)[256],int,int):loc_32E278F2p ... .text:32E274FF .text:32E274FF var_104 = byte ptr -104h .text:32E274FF arg_0 = dword ptr 8 .text:32E274FF arg_4 = dword ptr 0Ch .text:32E274FF arg_8 = dword ptr 10h .text:32E274FF .text:32E274FF push ebp .text:32E27500 mov ebp, esp .text:32E27502 sub esp, 104h .text:32E27508 push ebx .text:32E27509 xor ebx, ebx .text:32E2750B cmp [ebp+arg_4], ebx .text:32E2750E push esi .text:32E2750F push edi .text:32E27510 mov esi, ecx .text:32E27512 jz loc_32E275CE .text:32E27518 mov ecx, [ebp+arg_8] .text:32E2751B cmp ecx, 0Ch .text:32E2751E jg loc_32E2782B

On voit ici que le 3e argument de la fonction est bien compare a MAX_LWZ_BITS (12), et si la taille du code est superieure, on sort. Donc Microsoft etait au courant de ce bug au minimum 3 ans avant qu'il ne soit corrige dans les bibliotheques publiques - et bien entendu la vulnerabilite n'a pas ete reporte par Microsoft. Notez que je ne blame personne, je me contente de constater :) Responsible Disclosure, tout ca.

Encore une fois je ne dispose pas de tous les elements, donc si quelqu'un a quelque chose a ajouter, feel free!

Et pour finir une entree marrante d'un blog de Microsoft qui n'a rien a voir avec le sujet precedent:

http://blogs.msdn.com/david_leblanc/archive/2010/04/16/don-t-use-office-rc4-encryption-really-just-don-t-do-it.aspx

EDIT: le fix est aussi present dans FP4 pour Windows 2000, donc les 3ans se transforment d'un coup en beaucoup plus.

FIRST Conference 2010: In Miami, Bitch

La 22e conference du FIRST se deroulera du 13 au 18 Juin 2010 a Miami. Le programme est disponible ici. Je n'ai pas trop prete attention au deroulement de ces conferences depuis que j'ai quitte le "milieu", mais bon cette annee c'est special vu que ca se deroule pas loin de mon WHQ - et Dave presentera une keynote! Je serai dans les environs, histoire de dire bonjour aux anciennes connaissances - ou me faire cracher dessus.

Si vous comptez vous deplacer pour l'occasion, qu'il n'y a pas de gros nuage volcanique, etc., envoyez moi un mail et je tacherai de vous faire decouvrir Miami et Miami Beach!

Ultra Music Festival 2010

Gros line-up comme d'habitude pour l'UMF cette annee. Miami va etre relativement penible a vivre pendant la semaine de la Winter Music Conference, mais bon on va tacher de faire avec.

Barbouzeries

27 minutes qui valent le detour.

Un peu d'humour

Vu que je n'ai rien d'autre a poster: