3 Comments

  • 1. Baboon  |  novembre 25th, 2007 at 11:35

    simpa comme article !
    J’aime assez ce genre de bricolage (meuh non te vexe pas)
    C’est fastoche a comprendre , c’est joli , j’adoooore.
    Sinon je te demanderais sur irc quel est donc cet AV / FW mal foutu
    :P

  • 2. mxatone  |  novembre 26th, 2007 at 10:02

    Je ne serais pas aussi critique que toi sur l’implementation, la creation de règles appliquées à un device ou le filtering efficace de device pouvant etre linké symboliquement n’est pas une tache facile (loin de la).

    Sinon l’utilisation de critical section n’est pas une solution, ca permet juste que 1 ou plusieurs threads ne se trouve pas dans la même partie de code au même moment, c pour ca qu’il y a une variable qui definit la critical section. Ca n’arrete pas tous les threads du processus le temps de tes commandes (heureusement).

    Même dans le cas ou tu arriverais a prendre la main sur les threads du process pendant un cour instant, les pertes en synchronisation interprocess serait catastrophique surtout sur un call comme NtCreateFile. Tu ne peux pas arreter tous les threads d’une application pour un check de securité … Surtout qu’avec l’infrastructure Windows tu peux utiliser un autre process pour faire exactement la même chose (cf OpenProcess, Read/WriteProcessMemory et DuplicateHandle qui est possible sur un process remote). Tu peux toujours passer à DISPATCH_LEVEL ou en exclu tout processeur pour cheque un handle … heu quoi que NON :p

    Au niveau des candidats, la liste pourrait etre longue quand on voit l’implementation des syscall par certains antivirus, néamoins ce bug est très spécifique et c’est un exemple classique qui montre les problèmes rencontré dans le kernel, ne cherchez pas comment l’utiliser sur un antivirus donné car il est fort probable que bien d’autres bugs soit présent et pas celui-ci.

  • 3. admin  |  novembre 28th, 2007 at 20:26

    Ha vi, je me suis trompé pour les criticals sections. Bien vu encore mx, merci :]

Trackback this post