Mitigations d'intégrité de flux Windows : CFG et CET

Ceci est le troisième tutoriel de l'espace Exploitation Windows, écrit du point de vue du défenseur. Les guides sur l'écrasement SEH et le contournement de DEP se sont tous deux terminés sur un ensemble de mitigations Windows. Nous expliquons ici chacune d'elles — ce qu'elle vérifie, comment l'activer et où sont ses limites.

La réponse en couches aux deux techniques

L'histoire de l'exploitation Windows est une succession de technique-puis-mitigation, la même forme que dans les espaces Linux et ARM :

SafeSEH et SEHOP

SafeSEH est à la compilation : l'éditeur de liens construit une table de chaque gestionnaire d'exceptions valide du module, et le répartiteur refuse d'appeler un gestionnaire absent de cette table. L'astuce du pop pop ret-vers-shellcode échoue parce que cette adresse n'est pas un gestionnaire enregistré.

SEHOP est à l'exécution : il parcourt la chaîne SEH lorsqu'une exception est répartie et vérifie qu'elle se termine par l'enregistrement final attendu. Une chaîne corrompue par un débordement ne valide plus. Point crucial, SEHOP couvre les modules construits sans SafeSEH, comblant la lacune des tiers.

Control Flow Guard (CFG)

CFG protège l'arête avant. Le compilateur (/guard:cf) marque les cibles d'appels indirects valides, et l'OS en tient un bitmap ; chaque appel indirect est vérifié par rapport au bitmap avant de s'exécuter. Une chaîne qui appelle au milieu d'une fonction, ou vers des données, n'est pas une cible valide et est bloquée.

Ses limites reflètent le CFI d'arête avant sous Linux : il est à gros grain (toute entrée de fonction valide est autorisée, si bien que des cibles valides mais dangereuses peuvent rester atteignables), il ne protège pas les retours, et un module sans CFG dans le processus l'affaiblit. Cette lacune d'arête arrière est la raison d'être du CET.

CET matériel : la pile fantôme

Le CET d'Intel, activé via /CETCOMPAT, ajoute une pile fantôme matérielle : une copie protégée des adresses de retour vérifiée à chaque ret. Une chaîne ROP qui a écrasé des adresses de retour sur la pile normale ne correspond plus à la copie fantôme, et le processus est terminé. Le CET est le partenaire d'arête arrière de l'arête avant du CFG — ensemble, ils contraignent les deux directions dont la réutilisation de code a besoin, exactement comme PAC+BTI le font sous ARM.

Ce que cela apprend à un défenseur

• Activez l'ensemble complet, et vérifiez chaque module. /guard:cf, /DYNAMICBASE, /HIGHENTROPYVA, /NXCOMPAT, /SAFESEH (32 bits) et /CETCOMPAT ferment chacun une étape ci-dessus. Le maillon faible récurrent est une seule DLL tierce à laquelle il manque l'un d'eux — auditez tout le processus, et utilisez Exploit Protection pour appliquer par processus là où vous ne pouvez pas recompiler.
• Les arêtes avant et arrière sont des problèmes distincts. CFG seul laisse les retours ouverts ; CET seul laisse les appels indirects ouverts. Livrez les deux sur du matériel compatible.
• Les mitigations sont des multiplicateurs de coût, pas des remèdes. Comme sur toutes les plateformes, elles rendent l'exploitation coûteuse et peu fiable ; le correctif durable est d'empêcher le bug de corruption mémoire — voir langages sûrs pour la mémoire.

Points clés à retenir

• SafeSEH (table de gestionnaires à la compilation) et SEHOP (vérification de chaîne à l'exécution) mettent en échec l'écrasement SEH ; SEHOP couvre les modules sans SafeSEH.
• CFG vérifie les cibles d'appels indirects par rapport à un bitmap (arête avant) ; il est à gros grain et ne protège pas les retours.
• Le CET matériel ajoute une pile fantôme (arête arrière) ; CFG + CET ensemble reflètent le BTI + PAC d'ARM.
• Activez l'ensemble complet des flags sur chaque module ; une seule DLL non durcie est la lacune habituelle.

Ceci complète l'arc Exploitation Windows : écrasements SEH, contournement de DEP avec ROP, et les défenses CFG/CET. Pour le tableau multiplateforme, voir la pile de mitigations.