Le bon hacker et le mauvais hacker

Ce mois-ci, c'est le mois de l'"underflow" pour Microsoft. Chose relativement surprenante mais comprehensible puisque les "overflows" sont tous patches depuis belle lurette. Ou pas.

Hier a ete publie en urgence le correctif MS08-067. Touchant une sous fonction de CanonicalizePathName, meme fonction ayant presente la vulnerabilite patchee par Microsoft avec MS06-040. C'est moche. Il y a 42 experts securite chez Microsoft qui ont bosse sur le patch (indice: nombre fictif) et ils n'ont pas vu cette faille juste sous leur nez! Bon allez, je ne les blame pas je ne l'ai pas vu non plus. D'un autre cote je ne bossais pas chez Immunity a l'epoque, mais chez EADS donc necessairement moins de temps a ecrire des exploits (excuse bidon numero 42).

La vulnerabilite est vicieuse. Je vous conseille d'aller jeter un oeil au blog du sieur Sotirov pour voir le reverse de la fonction vulnerable.

Pourquoi donc le mois de l'"underflow"? Avec MS08-062, on avait une copie de buffer debordant devant le buffer et pas derriere, pareil avec MS08-067. C'est nouveau, c'est beau. Le stack cookie est derriere le buffer, donc avec un underflow, on ecrase le stack frame d'une fonction fille et pas le cookie de la fonction ou le buffer est defini, et c'est gagne. Grandiose! Je ne sais pas si c'est tres clair, c'est complique a expliquer.

Apres on peut aller voir le PoC sur milw0rm. Et c'est la qu'on voit le mauvais hacker.

This is because it depends on the state of the stack prior to the "overflow".You need a slash on the stack prior to the input buffer.

Declencher la vulnerabilite est ridiculement facile. Toute la difficulte reside dans la possibilite d'obtenir un '\' unicode a un endroit determine pour que votre "underflow" soit fiable. Cela prend 10min lorsque l'on comprend ce qui se passe, ou apparemment c'est trop complique pour qu'on s'y attarde pour les autres.

Deception

Autant des fois je m'emerveille sur la qualite et la complexite de certains bugs, autant des fois je me demande comment d'autres ont pu survivre jusqu'en 2008.

Et quand je regarde MS08-063, je me demande meme comment ca a pu passer 2001.

Une des fonctions au coeur de SMB, un parametre trop long, une soustraction, un debordement. Et paf le kernel. N'importe quoi. Une vulnerabilite comme ca, je m'en veux de ne pas l'avoir vu plus tot. Encore aurait-il fallu que je regarde le dit driver.

/sigh

Edit: En fait il y a pire avec MS08-059. La fonction RPC s'appelle _SnaRpcServer_RunExecutable et prend 2 chaines de caracteres en parametres. Le service RPC de HIS ecoute sur un port TCP/IP dynamique, pas d'authentification bien sur. Tres 1992.

Tres bon mois!

Encore un coup des Chinois!

Hacked by Chinese all over again!

Ce Microsoft Tuesday etait plein de bonnes surprises. Tout d'abord Microsoft nous fournit ce mois-ci plethore d'information sur les bugs, soit dans les avis officiels, soit sur le blog de SWI. Cool. Nous avons aussi maintenant le droit a un indice d'exploitabilite des bugs. Cette fois-ci MS n'a plus le droit a l'erreur, ce n'est plus un individu lambda qui va annoncer sur un blog 'Mais non ce n'est pas exploitable, LoL!', c'est une "position officielle".

On pourra s'etonner aussi du fait que l'on trouve une faille reportee par le CERT/CC utilisee dans des attaques "ciblees". Ce n'est pas la premiere fois que cela arrive, neanmoins dans les cas precedents, ce n'etait pas mis en avant de la sorte. On supposera que la vulnerabilite en question a ete trouvee lors d'une session forensique rondement menee par nos amis CERTiens. Bien joue. Ca change du PHP include.

Dans nos HQ miamiens, lorsqu'un truc comme ca arrive, Dave dit que c'est Chinois. Ca pourrait etre Russe ou Indien pour autant qu'on le sache, mais bon, c'est Chinois pour nous. Et c'est plutot bien fait.

La vulnerabilite est saugrenue. Tout d'abord le filtre ISAPI en question n'est accessible que post-authentification. Passe encore. Vous envoyez votre requete IPP en demandant au filtre de venir recuperer des informations sur telle imprimante. Bien evidemment il s'avere que cette imprimante est en fait hebergee dans vos locaux, et puis que ce n'est pas une imprimante du tout mais quelques lignes de python qui simulent un serveur SMB/RPC. Apres avoir initie la connexion et effectue quelques requetes, une des reponses de notre "imprimante" est utilisee n'importe comment par le filtre ISAPI, qui va allouer de la memoire a partir d'un parametre de la reponse en copier des donnes dans le buffer alloue en se fondant sur un autre.

Quelle sale histoire. Un bon heap overflow des familles, mais complexe a mettre en oeuvre, et a trouver... Ils sont forts ces Chinois! Moralite, filtrez le SMB sortant.

C'est la rentree!

La rentree c'est cool.

D'abord parce que toutes les series TV reprennent. Avec la greve des scenaristes durant la precedente saison, la plupart des series se sont vu ampute d'une bonne partie de leurs episodes. Chuck a repris Lundi; ce soir, c'est au tour de Pushing Daisies. Bas, eternel amateur de Buffy the Vampire Slayer, me conseille ardamment de regarder True Blood. Quant a Dexter, il est de retour depuis Dimanche dernier. O joie.

La rentree cela veut aussi dire que la temperature a Miami va se calmer un peu, que l'on en a bientot termine avec la saison des ouragans, et que l'on peut se remettre au soleil sans se retrouver couvert de transpiration au bout de 10s. Si tant est que l'on aime ca.

Et puis la rentree, c'est aussi passer quelques jours a Hawaii, et prendre son cafe du Vendredi matin sur Waikiki beach. Trop dure la vie.