Heap Overflows a Miami en Janvier

Pas de mise a jour ces derniers temps, il ne se passe pas grand chose.

Debut Janvier aura lieu a Miami Beach un training sur les Heap Overflows organise par Immunity. D'habitude je ne parle pas de ce genre de choses sur ce blog, si ce n'est que ce coup-ci, deux francais seront aux commandes: Nicolas Pouvesle et moi-meme. Le training sera donne en Anglais (vu que les participants deja inscrits sont anglophones), mais peut etre que certains lecteurs de ce blog trouveront un interet a avoir des "trainers" francophones. L'autre avantage sera bien evidemment de passer une semaine a Miami Beach a une periode de l'annee ou il fait plutot froid ailleurs :)

Pour plus de details sur le training, contactez admin a immunityinc point com.

L'honneur est sauf!

Comme certains d'entre vous auront pu s'apercevoir, une technique d'exploitation du bug SMBv2 a ete publiee sur le blog de Metasploit par Piotr Bania (qui ne travaille pas pour Immunity comme pourraient le penser certaines personnes mal informees - cf. FLS). Et elle se revele plus fiable que la precedente de Stephen Fewer (qui ne marchait jamais).

Donc l'honneur est sauf! Je ne serai pas a l'origine de la nouvelle apocalypse numerique, comme le prophetisait certains, et je pourrai dormir paisiblement pendant que les jeunots pirateront des honeypots avec l'exploit Metasploit.

Quelques precisions/pensees sur le bug SMBv2:

• Malgre tout le buzz qui en a ete fait (y compris par Immunity), je trouve que le bug au final n'est que peu interessant, pour la simple raison qu'il n'est exploitable que sur plateformes x86.
• Si vous avez du x64, vous etes tranquille (pour le moment, mais ca ne devrait pas changer - sauf intervention divine), parceque les parametres de la fonction sont passes par registres et non par la pile, ce qui rend la technique de stack shifting inutilisable. Du 2008 x86 c'est super rare (3GB de memoire sur un serveur en 2009 c'est pas super utile), et du Vista x86, meme si c'est plus repandu, ca reste tout de meme rare (cf. pentests recents que j'ai pu mener).
  
• Comme d'habitude, pas grand monde n'a compris ce qui se passait, c'est pas nouveau, la securite informatique ce n'est pas un succes. Si vous avez des problemes de comprehension, evitez de l'ouvrir, vous passerez pour plus stupide que vous ne l'etes.
• Il est dommage de constater que l'exploitation d'un bug de nos jours est si problematique. Il aura fallu ~3 semaines a Stephen Fewer pour creer un exploit qui ne fonctionne pas souvent (a cause de l'adresse choisie dans le Bios/HAL), et ~1 mois a Piotr Bania pour arriver a quelque chose de fonctionnel grace, semble-t-il, a l'exploit publie precedemment. Beau boulot neanmoins des 2, puisque le resultat est la!

C'est beau Internet.

Flyer

Credit: Nicolas Waisman

Merci Microsoft!

http://blogs.technet.com/srd/archive/2009/09/18/update-on-the-smb-vulnerability.aspx

We have analyzed the code ourselves and can confirm that it works reliably against 32-bit Windows Vista and Windows Server 2008 systems. The exploit gains complete control of the targeted system and can be launched by an unauthenticated user.

Je pense que c'est la premiere fois que je vois ca. Ca fait plaisir :)

Bonne nouvelle du jour!

Toto a trouve un autre code path qui fait fonctionner l'exploit contre un SP1, et Skylar l'a implemente dans la nuit. Le tout est relativement fiable (tres), et avec du banner grabbing, le choix de la cible est automatique. Ce qui en fait une vulnerabilite "wormable" :)

Trop dure la vie.

SMBv2 Exploit Video

http://www.immunityinc.com/documentation/smb2.html

Quelques commentaires:

• Cet exploit releve de la magie noire plus que d'autre chose. Il est vraiment beau. Vraiment. J'en pleurerais tellement il est beau.
• Le coup du RDTSC n'est pas une blague. On verifie l'uptime de la machine via une requete Negotiate SMBv2 standard, la reponse inclut le BootTime et CurrentTime du serveur. En fonction, on lance l'exploit. Si le RDTSC est trop haut, reboot et zou.
• Ca fait plaisir de bosser avec des gens comme Skylar et Toto, ca rend la vie plus facile.
• Pourquoi SP2 seulement? Parceque dans le SP1 une des structures dont nous avons besoin n'est pas alignee sur 8 octets, et ca fout en l'air la technique. Mais on travaille a une solution :)
• Il reste du boulot sur cet exploit, mais je suis sur un PenTest pour le reste de la semaine :(

Edit: Dave va refaire une video parcequ'il trouve la mienne toute pourrie. La faute au multimedia sous Ubuntu! Ca droppe des frames a gogo.

Exploit SMBv2 distant pour Vista!

On a un int3 fiable sur un Vista SP2 :) Et ca passe au travers de l'ASLR, etc. Reste a caser un shellcode dedans. Et a rooter du 2008 Server en attendant qu'un patch sorte un jour, peut-etre. Le prochain MS Tuesday est dans 3 semaines++, donc s'il font pas un out-of-band, ca va saigner! Ah, si seulement j'etais un pirate... Enfin bon, on arrive en fin de journee ici, donc on finira ca demain.

Gros bravo a Nicolas P. qui a reussi a comprendre mon code :)

Un peu plus pres du remote

Maintenant on transforme le call srv2!ValidateRoutines[i] en call x (avec ici x=0x42424242) en remote (un seul paquet). Le probleme c'est l'ASLR. C'est sympa de pouvoir appeler quelque chose qui va toujours etre au meme endroit, mais ca ne sert pas a grand chose dans Vista++. Le progres par rapport au Local, c'est qu'on est plus oblige d'appeler 0x00000000. C'est beau. Mais c'est pas gagne encore.

Quelques pensees en vrac sur la vulnerabilite SMBv2

• Il est dommage de poster une vulnerabilite de ce type au grand public sans vraiment savoir quelles en sont les consequences. Si vous ne savez pas quoi faire de vos vulnerabilites, je peux vous en racheter les "droits", surtout qu'avec un peu de temps dessus, on peut en faire quelque chose de beau.
• Pourquoi pas un Local et pourquoi ce n'est pas boiteux? Il s'avere que contrairement a la plupart des bugs qui aboutissent a une elevation de privileges, l'utilisateur ici ne controle pas la memoire du processus userspace qui joue a touche-pipi avec srv2.sys. Ie.: pas possible d'allouer a 0 et de sauter a 0. Tout le monde doit maintenant connaitre la primitive du bug (call srv2!ValidateRoutines[i] avec 0<=i<=65535), et tout le monde a du penser a un moment qu'il etait facile d'avoir un pointeur vers 0 dans la section .data. Oui c'est facile, non c'est pas exploitable de la sorte vu que vous ne controllez pas ce qui est 0 (qui sera non mappe). Et pareil pour toute adresse du userland. ALSR = pas gagne.
• ASLR noyau, ASLR en espace utilisateur, ca vous rend la vie compliquee. Tres. Et meme si vous avez des vulnerabilites a la con comme celle-la dans Vista, ca sera toujours mieux que d'avoir XP. Vraiment. Le seul truc qui manque, c'est le NX noyau.
• Au final il aura fallu ~2 jours (2*8h) de boulot pour faire un local (et oui je faisais le guignol a NY quand c'est sorti), le remote probablement le triple, si tant est que cela soit possible.

Edit: le lien vers le site de CEU: http://www.immunityinc.com/ceu-index.shtml

Exploitation de la vulnerabilite SMBv2

Cela faisait un moment que je n'avais pas eu l'occasion de me faire les dents sur une chouette vulnerabilite. Quelque chose qui resiste, mais qui finit par casser, apres suffisamment d'efforts. De nos jours, soit on tombe sur quelque chose d'infaisable, soit sur une injection de commande version 1992AD.

L'exploitation de la vulnerabilite est extremement interessante, car elle requiert une facon de penser completement differente. Alors que certains s'interessent a des techniques plus "classiques", je me suis brise les synapses sur un autre moyen, mais qui se revele plutot lucratif au final. Le resultat est un local fiable (sur Vista SP1 a jour, SP2), et peut-etre un distant dans les jours qui viennent :) (Si on me colle pas sur du consulting!)

Edit: Output de l'exploit local: http://pastebin.com/m6c7d30ce (ca sauve de la place)

"Exploitability Index" ou comment perdre son (mon) temps

Depuis quelques mois deja, Microsoft a rajoute un "Exploitability Index" a ses bulletins mensuels. Cet indice d'exploitabilite est decrit sur cette page. Il consiste en un simple chiffre:

1. Consistent exploit code likely
2. Inconsistent exploit code likely
3. Functionning exploit code unlikely

Le modele a fait l'objet d'un papier du sieur Bas Alberts (disponible ici). Et les gens de Microsoft se plantent rarement dans leur analyse. Un post du "Silver Surfer" Mike Reavey couvre le sujet en analysant un mois de bulletins et d'exploits.

Somme toute, il s'agit d'une bonne metrique si vous voulez prioriser un patch lors d'un Microsoft Tuesday, soit en tant qu'administrateur soucieux de securiser votre reseau, soit en tant que "differ" soucieux d'avoir un exploit fonctionnel au plus vite.

La ou le bat blaisse pour moi, c'est quand Microsoft se plante. L'erreur n'est pas dans la sous evaluation du risque, mais dans la surevaluation.

Prenons l'example du Microsoft Tuesday de Juin 2009. Plusieures failles interessantes (comprenez anonymes distantes), dont MS09-018 et MS09-022.

Le second bulletin, ciblant le service Spooler a ete boucle en moins de deux heures pour la version 2000 (XP n'est que local d'apres le bulletin).

Le premier touche Active Directory, comprend 2 failles, un free() invalide et une fuite de memoire. Un free() d'un pointeur sous votre controle, c'est exploitable sous Windows. Et l'indice d'exploitabilite pour cette faille etait de 1 (cf. blog du MSRC). Donc Toto se met au boulot histoire de voir de quoi il retourne. Apres quelques heures de lecture intensive de lignes d'assembleur et d'envoi de paquets LDAP, il annonce "Je ne vois pas comment ca peut etre exploitable ...". Je regarde, pas mieux.

La primitive du bug est un free(pointeur+X) avec 1<=X<=6, et le pointeur est fixe pointant sur des donnees sous votre controle. Un tel bug pourrait etre exploitable si X=8, 16 ou 24, etc. Par contre si (pointeur+X)&7!=0, RtlFreeHeap() vous envoie chier joyeusement et rien ne se passe. Pourquoi cet indice d'exploitabilite de 1?? C'est rageant, on continue a bosser dessus en pensant qu'on a rate quelque chose. Et puis aujourd'hui, on voit sur le bulletin:

V1.1 (June 10, 2009): Corrected the rating and key notes for CVE-2009-1138 in the Exploitability Index.

Alors la. L'indice de 1 est passe a 3, et une petite ligne a ete ajoutee:

However, due to additional checks on the heap, a functioning remote code execution exploit is very unlikely.

C'est moche :( Resultat je ne vais plus faire trop confiance a leur "Exploitability Index"...

Edit: extrait du bulletin iDefense:

06/05/2009 - Microsoft informs iDefense that the Bulletin was promoted
to potential Code Execution
06/08/2009 - iDefense requests clarification, offers further insight
06/10/2009 - iDefense reiterates request
06/10/2009 - MS Responds that they agree that code execution is very
unlikely and will change the Exploitability Index
06/11/2009 - MS Changes Exploitability Index from 1 to 3
06/11/2009 - Coordinated public disclosure

Les "Certifications"

Aujourd'hui je recois un mail d'un mec qui veut des informations a propos de VMware. La personne en question est CISSP, SANS GCIA, MCSE, CCSA, CCSE, CSA, CCNA, et CNA. Ca fait beaucoup. Les questions sont: Et votre exploit il fait quoi??? Et ca marche sous ESX???

Donc apparemment plus avez de certifications, moins vous savez utiliser Google. Et ca semble diminuer d'autant votre comprehension de l'Univers aussi. Et les questions (ou leurs reponses pour etre exactes) sont destinees a etre ajoutees a des slides pour une presentation ayant lieu dans 2 semaines a une grosse conference.

C'est pas mal de decouvrir ce qui se passe deux semaine avant. Ca doit etre ce qu'on appelle la veille.

MOSDEF over Direct3D

Des fois, je fais des trucs a la con.

Un example est quelque chose sur lequel je bosse un peu en ce moment: MOSDEF Over Direct3D. C'est le genre de trucs qui va m'etre utile une seule fois, mais dont le concept est intellectuellement stimulant. Le seul interet de MOSDEF Over Direct3D: le bug VMware. Ou comment s'assurer du maintient d'un canal de communication entre l'Hote et l'Invite sans se fier a des fonctionalites pouvant etre absentes (reseau) ou desactivees (vmrpc, vmci, etc).

La solution: etablir un canal de communication via le Frame Buffer de l'Invite. Dans la mesure ou le Frame Buffer est sense etre 'abstrait' par les multiples couches graphiques de Windows, il n'est pas evident de pouvoir y acceder directement en Ring 3. Sauf via DirectX/Direct3D.

Le jeu est donc d'ecrire un proxy TCP (MOSDEF se fonde sur du TCP de base) vers Direct3D pour l'Invite, puis du cote de l'Hote: lecture et execution du code et reecriture du resultats dans le Frame Buffer (facile).

C'est bien de se faire plaisir de temps en temps. Le tout devrait faire l'objet d'une presentation si je suis accepte a Vegas.

Sans le SANS ...

... que ferait-on? Ils ont decide de se reveiller ce matin pour une raison que j'ignore:
VMware exploits - just how bad is it ?

Pas mal les mecs. Il leur a fallu 2 semaines pour realiser ce qui se passait. Et dire qu'ils sont senses representer une sorte d'elite de la securite, toujours au courant de ce qui se passe, etc.

Edit: Au passage, un CVSS de 10! (NIST)

La bonne nouvelle c'est qu'Ulduar, la nouvelle instance de Raid de WotLK sort aujourd'hui. On va enfin pouvoir faire autre chose!

HP NetTop

Page Wikipedia:
http://en.wikipedia.org/wiki/NetTop

Le document "technique":
http://h71028.www7.hp.com/enterprise/downloads/HP_NetTop_Whitepaper2.pdf

Le "Virtual Air Gap" (c) HP:

Allez, pour bien commencer le Samedi

Tire du Blog de VMware Fusion:
http://blogs.vmware.com/teamfusion/2009/04/vmware-fusion-204-update-now-available.html

"2.0.4 already?", you ask. That's right, we are releasing VMware Fusion 2.0.4 today to address a critical security issue. At VMware, we take security very seriously and always stay vigilant to provide the safest products and solutions possible.

Maintenant, on sait que CLOUDBURST a ete fixe en silence avec VMSA-2009-0005 (dans Workstation du moins), puis annonce avec VMSA-2009-0006. Question: quel produit est specifie non affecte dans 0005, et patche une semaine plus tard avec 0006?

Quelque part ca suit la politique de l'OS sur lequel ca tourne.

CVE-2009-1244

Il semblerait qu'apres une tentative de patch silencieux de la part de vous-savez-qui, CLOUDBURST se soit vu assigner un CVE:

http://lists.vmware.com/pipermail/security-announce/2009/000055.html

"A critical vulnerability in the virtual machine display function might allow a guest operating system to run code on the host."

J'aime bien le "might". Heureusement qu'on est Vendredi.

Mais bordel de merde

EL OH EL du jour:
http://www.reuters.com/article/topNews/idUSTRE53729120090408

Google translating this blog

There seems to be a lot of non French people trying to read this blog lately, and most of them are using Google Translate to get something they can understand. You have to be aware that Google Translate is doing a terrible job at it. I think the main reason is that I am typing everything on Qwerty keyboards, and thus not bothering with accents and some other special characters involved in the French language. I am also using a bit of slang. The resulting is often something that doesn't have at all the meaning it has in French.

Having a look at the previous post translated, the last paragraph turns out to be funny: [Google-EN] "At this time there, I have done evil, and I am furious." for [FR] "Sur ce coup la, je me suis fait avoir mechamment, et je suis furieux." which means more something like [EN] "On this one, I got badly owned and I am furious". I am not sure where the "I have done evil" comes from.

I think Google is trying to make it look worse than it is. OMG CONSPIRACY.

I would add that the reason I maintain this blog in French, is that it's mostly the only place where I can still use my mother tongue. And when you realize that sometimes you struggle to find a word in your first language while it comes fairly easily in English, it means that every exercise is good.

Vulnerability Disclosure en 2009

Il semblerait que personne n'apprenne quoi que ce soit. Jamais. Ca serait con de tirer des lecons des erreurs des autres hein?

Curieusement, le seul editeur a avoir regulierement progresse dans le domaine du "on-va-eviter-de-tenter-de-cacher-des-trucs-et-se-faire-refaire-le-trou-du-cul-deux-jours-plus-tard" est Microsoft. Bravo a eux. Ils ont appris ca en 2004, et depuis ils ne le refont plus. Quelques hoquets ici et la, mais globalement OK.

Nous voici en 2009. Certaines compagnies que je vais eviter de citer (en fait j'en ai une seule en tete), pensent toujours en 2009 que ce genre de comportement est non seulement acceptable, mais va leur eviter d'avoir a annoncer que leur produit (certifie EAL 4 machin-truc) n'est pas si solide que ca (comprenez "a-chier-EL-OH-EL").

Sur ce coup la, je me suis fait avoir mechamment, et je suis furieux. Non seulement ce bug n'aurait jamais du etre "disclosed". Mais la gestion qui en est faite en ce moment est pitoyable. C'est ridicule. Je ne peux malheureusement pas controler ce que les "hautes autorites" decident. Et je n'ai qu'a executer. Super. Maintenant on me demande de la fermer. Ce n'est plus ce que c'etait.

Edit: Quelques lignes de Burn After Reading

CIA Superior: What did we learn, Palmer?
CIA Officer: I don't know, sir.
CIA Superior: I don't fuckin' know either. I guess we learned not to do it again.
CIA Officer: Yes, sir.
CIA Superior: I'm fucked if I know what we did.
CIA Officer: Yes, sir, it's, uh, hard to say
CIA Superior: Jesus Fucking Christ.

CLOUDBURST: Hacking 3D

Et dire que je pensais que la 3D et le hacking, c'etait bon pour Hackers et les fantasmes du genre. J'avais tort (une fois du plus diront certaines mauvaises langues). Il n'est pas necessairement connu de tout le monde que les produits VMware implementent un certain support 3D depuis un long moment. Et oui, on peut jouer a WoW dans une VMware...

Les fonctionalites 3D etaient tout d'abord presentes et desactivees par defaut. Puis les dernieres versions de Workstation (6.5) et ESX (4.0) ont passe ces fonctions en configuration par defaut. Si vous creez une nouvelle VM, vous aurez le support 3D. Si vous ouvrez une vieille VM, la case sera decochee par defaut mais le code tout de meme execute, resultant en un message d'erreur.

Ces differentes fonctions 3D correspondent en gros aux fonctions de coeur de Direct3D et OpenGL (je n'y connais pas grand chose, j'ai juste Google quelques noms). Les fonctions 3D executees par un programme dans le Guest sont transmises via le driver video a l'Hote qui les "parse" et affiche le resultat. Ce qui est extremement cocace dans le cas de ESX 4.0, c'est que l'Hote parse tout de meme les commandes video, meme si la "console" du Guest est soit un VNC ou un TS . Aucun interet de mon point de vue, mais passons. Le driver video des VMware Tools simplifie le travail, mais n'est pas necessaire a l'exploitation de l'Escape.

L'avantage (pour les partisans du Chaos du moins) est que le traitement de ces commandes 3D implique une quantite impressionante d'operations de copie de buffers. Generalement depuis le Frame Buffer vers le Frame Buffer, ou du Heap vers le Frame Buffer et vice versa. Bien entendu, le Frame Buffer est partage entre le Guest et l'Hote.

La ou ca devient drole, c'est lorsque l'Hote ne verifie pas trop ce qu'il doit copier et ou il doit le copier. Le resultat: deux types de bugs.

1. Le premier est un leak de la memoire l'Hote dans le Guest. L'Hote copie une portion de la memoire dans le Frame Buffer, le Guest lit le Frame Buffer. Bingo part 1.
2. Le second est un write arbitraire (je simplifie la). Le Guest ecrit dans le Frame Buffer. L'Hote copie une portion du Frame Buffer vers sa memoire, et Bingo part 2.

En couplant les deux types de vulnerabilites, on peut tout faire. Fingerprinting de l'Hote, leak des pointeurs necessaires aux etapes suivantes de l'exploitation (l'ASLR n'est donc pas un problem), desactivation du DEP. J'entrerai davantage dans les details dans un prochain post.

VMware + Ubuntu = <3

Bon Xvidcap me chie dessus mechamment et ne capture que 10% des frames. Si quelqu'un connait un moyen alternatif de capturer une video de son bureau sous Ubuntu je suis preneur.

Resultat, ca passe beaucoup plus vite que pour Windows, je vous conseille de faire du frame par frame avec mplayer pour y voir quelque chose:

http://immunityinc.com/documentation/cloudburst-ubuntu.html

Le gros avantage de Ubuntu par rapport a Vista, c'est qu'il y a 0 protection, et que vmware-vmx est suid 0, ie: votre cher xcalc est root. C'est beau.

VMware Escape

http://lists.vmware.com/pipermail/security-announce/2009/000054.html

"a. Denial of service guest to host vulnerability in a virtual device

A vulnerability in a guest virtual device driver, could allow a guest operating system to crash the host and consequently any virtual machines on that host."

Edit: Suite a discussion avec VMware, il semblerait que le bug soumis par Andrew Honig soit bel et bien un DoS, dans un peripherique virtuel. Neanmoins la serie de bugs necessaire a l'execution de l'"escape" est corrigee (non creditee). Comprenez ce que vous voulez de cela. Ca commence a devenir complique ces conneries.

Et non, encore une fois, tout faux. Avec VMware 6.5.2 vient de mourir un des bugs Guest -> Host les plus fiables qui ait existe (a ma connaissance). Il s'agissait en fait de la combinaison de 3 a 4 bugs presents dans le code d'emulation d'un peripherique (execute sur l'hote):

• un memory leak
• un write relatif
• un write absolu
• et quelques goodies supplementaire pour desactiver DEP

L'avantage est qu'il est possible de rooter tout hote. Windows Vista SP1 avec son ASLR et DEP AlwaysOn, Ubuntu 8.04 LTS et son ... euh rien, ESX 4.0 (RC) et ses protections. Player, Workstation, tout.

Le code etait plus ou moins present depuis un long moment, et n'a ete active par defaut que dans la branche 6.5 de Workstation, et 4.0 de ESX.

J'attendais avec impatience la sortie de la finale de ESX 4.0, et le chaos que ca aurait engendre. Malheureusement la derniere version affectee aura ete le ESX 4.0 RC Hard Freeze.

Je me rejouis cependant de quelques details. Certaines organisations gouvernementales utilisent une solution fondee sur VMware pour le cloisenement du traitement des donnees secretes ou non. Fail. Je ne peux que sourire aussi en pensant a tous les honeypoteurs et autres analystes de malware qui font tourner des binaires dans leur VMware sans trop se soucier de quoi que ce soit.

Mais ne vous inquietez pas, personne n'a utilise un outil de la sorte dans le "wild". Ca se saurait, hein?

Sur ce, malgre un Samedi matin ensoleile, une semi gueule de bois, et une rage intense, je vais au taf pour faire une video Flash et mettre a jour CANVAS Early Updates avec une version de ce que j'avais prepare.

Edit: lien vers la video http://immunityinc.com/documentation/cloudburst-vista.html

Dead Bug continued

A la suite du deces (confirme) de mon protege, je vais m'efforcer de publier le papier pour le moment confidentiel couvrant le sujet, les implications. Je suis furieux. On ne tue pas quelque chose de ce potentiel.

Side note: j'uploade les photos de Ultra 2009 sous peu.

Apparemment Skype ca rapporte

Apparemment, la NSA n'est pas aussi douee que je le pensais a une lointaine epoque:
http://www.theregister.co.uk/2009/02/12/nsa_offers_billions_for_skype_pwnage/
Dire que certains faisaient ca pour le fun, et que d'autres essayaient d'en tirer des profits gratuitement. Vivement que les mentalites francaises (et leur portefeuille) changent.

Ou sinon c'est un gros piege de la NSA pour faire croire que les terroristes peuvent utiliser Skype en securite. Que ce soit l'un ou l'autre, chapeau.

Dead Bug

Un des ex-occupants de la piece CANVAS - Miami, FL

Aujourd'hui est un jour grave. Et non seulement parce que je suis plus vieux d'un an. Mais parcequ'un des plus beaux bugs sur lequel j'ai pu travailler vient d'etre condamne a la peine capitale. Une perle de technique et de fiabilite. Alors que certains vivent dans un monde ignorant totalement ce qui se trame dans leur dos, d'autres travaillent a faire de l'offensif un art aux ramifications insoupconnees. Plus jeune j'envoyais regulierement mes trouvailles aux editeurs divers et varies, fier d'avoir participe a la securisation des internets. Mon point de vue sur le sujet a evolue. J'aime les bugs vivants, j'aime savoir qu'ils peuvent servir a quelque chose, et parfois aider. Malheureusement je ne controle pas toujours l'avenir de mes creations. Peut-etre une intervention divine sauvera-t-elle celui ci, mais je n'y crois pas trop. Tristesse.

Au revoir, Grissom

Nouvelle annee, nouveau post. J'ai ete faineant sur la mise a jour de ce blog, de meme que sur mes reponses de mails de bonne annee. Je remedie au premier ici meme, je m'attacherai au second dans les jours qui suivent.

Donc meilleurs voeux pour 2009, etc. Beaucoup de reussite tout ca.

Ensuite hier soir s'est terminee une ere, l'ere de Gil Grissom dans CSI. Double episode, Grissom raccroche et quitte. Au profit de Laurence Fishburne semble-t-il, nouvel arrivant dans le staff. Beaucoup de changements cette saison dans CSI, avec la mort de Warrick (un des meilleurs episodes de la serie). Cela ne peut que me rappeler les Urgences, X-Files et autres, ou le depart de figures principales de la serie annoncent le debut de la fin (d'un autre cote les Law & Order continuent encore et encore).

Des trois, Mac Taylor, Horatio Caine et Gil Grissom, le dernier a toujours ete mon favoris.