Windows Server 2016 : corriger CVE‑2017‑8529 (IE) quand KB4038782 est introuvable — le réglage Registre indispensable

Un serveur Windows Server 2016 apparaît vulnérable à CVE‑2017‑8529, le KB d’origine (KB4038782) n’est plus visible dans le catalogue, et même après un CU récent la faille remonte. Voici la marche à suivre pour corriger durablement et faire passer les scans au vert.

Vue d’ensemble

Vous voyez CVE‑2017‑8529 (Microsoft Browser Information Disclosure) signalée sur un hôte Windows Server 2016. La page de l’avis d’origine renvoie au KB4038782 (septembre 2017), mais la recherche dans le catalogue Microsoft ne propose plus ce KB. Après installation d’un Cumulative Update récent (par exemple KB5036899 d’avril 2024 ou n’importe quel CU ultérieur), l’outil de VA continue pourtant d’indiquer la vulnérabilité. C’est attendu : le binaire est corrigé par les CU modernes, mais le correctif est livré désactivé pour éviter des régressions d’impression. Il faut donc activer une clé de Registre spécifique pour finaliser la mitigation et satisfaire les signatures des scanners.

Pourquoi KB4038782 n’apparaît plus

KB4038782 était un cumul mensuel de 2017 pour la branche 1607 (build 14393). Il a été supplanté par des Cumulative Updates successifs. Le catalogue n’affiche plus toujours les anciens cumulatifs supplantés — c’est normal. Les CU actuels pour Windows Server 2016 intègrent le contenu des correctifs antérieurs, dont celui qui traite CVE‑2017‑8529. Autrement dit : installez simplement le dernier CU disponible pour Server 2016 et vous disposez du code corrigé. Exemple de CU tardif de référence : juillet 2025 (OS Build 14393.8246). Toute version ultérieure convient également.

Le point clé que tout le monde oublie : la bascule Registre

Pour CVE‑2017‑8529, Microsoft a choisi de livrer le correctif désactivé par défaut afin d’éviter des effets de bord côté impression. C’est pourquoi, même après application d’un CU récent, certains scanners (Qualys, Tenable, etc.) continuent à remonter la vulnérabilité : ils vérifient explicitement la présence et la valeur d’une FeatureControl dans le Registre.

Clés à positionner (IE 11)

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX
  Valeur DWORD iexplore.exe = 1
• Sur systèmes 64 bits, en plus :
  HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX
  Valeur DWORD iexplore.exe = 1

Ces clés pilotent l’activation du correctif dans le moteur Trident/MSHTML pour le processus concerné (ici iexplore.exe). Sans elles, les signatures continueront d’indiquer “vulnérable”, même si l’OS est entièrement patché.

Solution rapide (récapitulatif opératoire)

1. Mettre à jour le serveur vers le dernier Cumulative Update pris en charge pour Windows Server 2016 (plus récent que KB5036899 inclus).
2. Activer la FeatureControl via les clés de Registre ci‑dessus (iexplore.exe = 1, y compris sous WOW6432Node en 64 bits).
3. Redémarrer le navigateur (voire le serveur selon vos procédures) et relancer le scan.
4. En environnement sensible à l’impression, tester les flux avant déploiement global (le correctif a été initialement “opt‑in” pour minimiser les régressions d’impression).

Procédure détaillée

Mise à jour vers le dernier CU

Installez un CU récent pour Windows Server 2016 (branche 1607). À titre d’exemple, la build 14393.8246 de juillet 2025 est un jalon tardif solide. Si une version plus récente existe au moment de votre intervention, privilégiez‑la. L’objectif est simplement d’être sur un CU qui contient le correctif binaire (tous les CU modernes le contiennent).

Activation du correctif via le Registre

Utilisez l’une des méthodes ci‑dessous selon vos préférences d’automatisation.

Invite de commandes (administrateur)

reg add "HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX" ^
  /v iexplore.exe /t REG_DWORD /d 1 /f

reg add "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE\_ENABLE\_PRINT\_INFO\_DISCLOSURE\_FIX" ^
/v iexplore.exe /t REG\_DWORD /d 1 /f 

PowerShell (administrateur)

$paths = @(
  "HKLM:\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX",
  "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX"
)
foreach ($p in $paths) {
  if (-not (Test-Path $p)) { New-Item -Path $p -Force | Out-Null }
  New-ItemProperty -Path $p -Name "iexplore.exe" -Value 1 -PropertyType DWord -Force | Out-Null
}
Write-Host "Bascule appliquée. Redémarrez IE / le serveur si nécessaire."

Déploiement à grande échelle (GPO)

1. Éditeur de gestion des stratégies de groupe > Configuration ordinateur > Préférences > Paramètres Windows > Registre.
2. Créer deux éléments “Registre” avec l’action “Créer” :
   • Chemin : HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX — Valeur : iexplore.exe (REG_DWORD) = 1
   • Chemin : HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX — Valeur : iexplore.exe (REG_DWORD) = 1
3. Lier la GPO aux OU contenant les serveurs 2016 concernés.

Autres méthodes (SCCM/ConfigMgr, Intune, scripts)

Vous pouvez pousser la bascule via un Baseline de conformité SCCM, un objet Intune “Paramètres du Registre” (si dispositif hybride) ou un simple package de scripts exécuté en contexte Système. Si vous avez un référentiel DSC, encapsulez la création des deux valeurs et rendez‑la idempotente.

Vérification locale de l’application du correctif

Après déploiement, contrôlez que les clés existent et que leur valeur est 0x00000001 (1).

Invite de commandes

reg query "HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX" /v iexplore.exe
reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX" /v iexplore.exe

PowerShell

$targets = @(
  "HKLM:\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX",
  "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX"
)
$results = foreach ($t in $targets) {
  $val = (Get-ItemProperty -Path $t -Name "iexplore.exe" -ErrorAction SilentlyContinue)."iexplore.exe"
  [pscustomobject]@{ Path = $t; "iexplore.exe" = $(if ($val -ne $null) { $val } else { "(absent)" }) }
}
$results | Format-Table -Auto

Vérification de l’état patch

Contrôlez également que le serveur est sur un CU récent :

wmic os get BuildNumber,Version

Ou en PowerShell :

(Get-ComputerInfo).OsBuildNumber

Sur Windows Server 2016 (1607), un numéro de build 14393.x récent indique que vous êtes bien sur une base moderne. L’important n’est pas de viser un numéro exact, mais d’être à jour et d’avoir activé la FeatureControl.

Pourquoi les scans restent parfois “vulnérables” après un CU

Les signatures de vulnérabilité pour CVE‑2017‑8529 utilisent généralement une logique “patch présent OU registry flag actif”. Or, pour cette CVE précise, même si le patch est présent, la correction est “opt‑in” côté moteur : c’est la valeur de la FeatureControl qui déclenche réellement la mitigation. De fait, de nombreux scanners font l’hypothèse suivante :

• Si la valeur HKLM\...\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX\iexplore.exe n’est pas égale à 1 → statut vulnérable.
• Si elle vaut 1 (et que l’OS est patché) → statut corrigé.

Cette approche évite un faux sentiment de sécurité lorsque le binaire est à jour mais que la protection n’est pas activée.

Effets de bord possibles et bonnes pratiques de test

Pourquoi Microsoft a‑t‑il laissé le correctif désactivé par défaut ? Parce que la mitigation touche des chemins de code liés à l’impression et peut, dans de rares cas, impacter l’aperçu avant impression, certains pilotes, ou des traitements spécifiques dans des applis legacy. Recommandations :

• Appliquer d’abord sur un lot pilote de serveurs représentatifs.
• Tester les scénarios d’impression éventuellement utilisés depuis le serveur (peu courant sur un serveur, mais possible dans certains contextes RDS).
• Prévoir un plan de retour arrière simple (valeur à 0 ou suppression de la valeur).

FAQ (questions fréquentes)

Le serveur n’utilise pas Internet Explorer. Dois‑je quand même activer la clé ?

Oui, tant qu’IE 11 et le moteur MSHTML sont présents (par défaut sur Server 2016), activer la FeatureControl est pertinent. Même si personne n’ouvre IE, des composants ou applis legacy peuvent héberger le moteur.

Puis‑je activer la mitigation pour d’autres processus hébergeant le contrôle WebBrowser ?

La clé FeatureControl est par processus. Par défaut, la plupart des guides n’exigent que iexplore.exe, ce qui suffit pour la majorité des scanners. Pour une surface de risque minimale, vous pouvez activer la même valeur pour certains hôtes connus (ex. excel.exe, winword.exe, wscript.exe, powershell_ise.exe) après validation. Évitez tout joker : les FeatureControls ne prennent pas en charge “*”.

Mon serveur est “Server Core”. Est‑ce applicable ?

Sur Server Core, IE autonome n’est pas installé, mais des composants MSHTML peuvent subsister selon les rôles ajoutés. Dans le doute, gardez la mitigation — elle est non intrusive et satisfait les scanners.

Dois‑je redémarrer le serveur ?

Un redémarrage du processus cible (iexplore.exe) suffit. Selon vos procédures, vous pouvez planifier un redémarrage global, surtout si la modification est poussée en masse via GPO.

Comment revenir en arrière ?

Replacez la valeur à 0 ou supprimez‑la. Exemple :

reg add "HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX" ^
  /v iexplore.exe /t REG_DWORD /d 0 /f

Dépannage : le scan reste en rouge

Si l’outil de VA signale toujours CVE‑2017‑8529, vérifiez les points suivants :

• Architecture : sur un OS 64 bits, la valeur doit être créée aussi sous WOW6432Node.
• Orthographe de la clé : le nom de la FeatureControl et de la valeur (iexplore.exe) doivent être exacts.
• Contexte : le script d’application a‑t‑il été exécuté en administrateur/Système ? Des GPO concurrentes écrasent‑elles la valeur ?
• Propagation GPO : forcer gpupdate /force, vérifier le Resultant Set of Policy.
• Cache / service de l’outil : certains scanners conservent le résultat précédent jusqu’à un nouvel inventaire complet.
• Redémarrage du processus : s’assurer qu’aucune instance d’IE ne restait ouverte lors du test.
• Fausse détection : comparez la logique de détection attendue (présence du patch ET/OU clé Registre) et ouvrez un ticket au besoin avec un relevé reg query.

Tableau récapitulatif

Élément	Attendu pour correction	Commande de contrôle	Résultat OK
CU Windows Server 2016	Dernier CU dispo (branche 1607, build 14393.x récente)	wmic os get BuildNumber	14393.x récent (ex. 14393.8246 ou ultérieur)
FeatureControl (x64)	HKLM\SOFTWARE\WOW6432Node\...\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX	reg query ... /v iexplore.exe	0x1
FeatureControl (natif)	HKLM\SOFTWARE\...\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX	reg query ... /v iexplore.exe	0x1
Redémarrage du processus	iexplore.exe relancé / sessions fermées	—	Oui

Script d’audit et de remédiation tout‑en‑un (PowerShell)

# Exécuter en admin / Système
$feature = "FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX"
$paths = @(
  "HKLM:\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\$feature",
  "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\$feature"
)

\$result = \[System.Collections.Generic.List\[object]]::new()

foreach (\$p in \$paths) {
\$exists = Test-Path \$p
if (-not \$exists) { New-Item -Path \$p -Force | Out-Null }
\$val = (Get-ItemProperty -Path \$p -Name "iexplore.exe" -ErrorAction SilentlyContinue)."iexplore.exe"
\$compliant = \$false

if (\$val -eq \$null -or \$val -ne 1) {
New-ItemProperty -Path \$p -Name "iexplore.exe" -Value 1 -PropertyType DWord -Force | Out-Null
\$val = 1
}
\$compliant = (\$val -eq 1)

\$result.Add(\[pscustomobject]@{
Path        = \$p
Value       = \$val
Compliant   = \$compliant
})
}

\$build = (Get-ComputerInfo).OsBuildNumber
\$osOk = \[int]\$build -ge 14393

\[pscustomobject]@{
OSBuildNumber         = \$build
OSBuildBranchOk       = \$osOk
FeatureControlResults = \$result
} | Format-List 

Contexte technique sur CVE‑2017‑8529

CVE‑2017‑8529 est une vulnérabilité d’exposition d’informations affectant les navigateurs Microsoft (moteur MSHTML/Trident). Le correctif ajuste la manière dont le moteur gère certains scénarios de rendu et d’impression afin d’empêcher une fuite potentielle de contenu inter‑origines. Sur la branche 1607 (Windows 10/Server 2016), le correctif a été rendu activable via FeatureControl pour limiter les régressions immédiates, d’où la nécessité de la bascule Registre décrite ci‑dessus.

Conseils de production

• Standardisez la bascule Registre dans votre référentiel d’état désiré (GPO, DSC, Ansible, Puppet, etc.).
• Documentez la logique de détection de votre outil de VA (ce qu’il attend, où il lit la valeur, dans quel contexte).
• Supervisez une mesure de conformité (par exemple un compliance item SCCM) qui retourne “non conforme” si la valeur diffère de 1.
• Communiquez auprès des équipes applicatives sur les rares cas d’impact impression et ouvrez une fenêtre de test.

Exemples de politiques de sécurité

Pour verrouiller durablement la posture :

1. Créer une GPO “CVE‑2017‑8529 – IE Print Fix” en niveau ordinateur, avec les deux entrées Registre et une boucle de renforcement (GPP en “Mettre à jour”).
2. Ajouter un Baseline SCCM qui vérifie les deux clés et remédie si nécessaire.
3. Inclure un contrôle périodique dans vos scripts d’hygiène (inventaire hebdomadaire).

Pièges courants

• Oublier WOW6432Node sur hôtes x64 : c’est la cause n°1 des “faux rouges”.
• Confondre la présence du patch et l’activation du patch.
• Écrasement GPO : une GPO de durcissement peut réinitialiser la valeur. Tracez l’origine via rsop.msc.
• Session IE persistante : le processus doit être relancé pour prendre en compte la FeatureControl.

Annexe : matrice d’évaluation rapide

État CU	Clé Registre	Risque réel	Résultat typique du scanner	Action recommandée
CU récent installé	Absente ou ≠ 1	Mitigation non active	Vulnérable	Activer la FeatureControl (valeur = 1)
CU ancien	Présente (=1)	Mitigation partielle (dépend du niveau binaire)	Variable selon signature	Mettre à jour vers le dernier CU
CU récent	Présente (=1)	Mitigation active	Corrigé	Conserver dans la base de conformité

Checklist prête à l’emploi

• [ ] Serveur sur un CU recent (branche 1607).
• [ ] HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX\iexplore.exe = 1.
• [ ] HKLM\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX\iexplore.exe = 1 (x64).
• [ ] Redémarrage d’IE / serveur planifié.
• [ ] Rapport de conformité ajouté au tableau de bord.

Résumé

En bref : KB4038782 ne s’affiche plus car il est supplanté par les CUs modernes. Installer le dernier Cumulative Update pour Windows Server 2016 ne suffit pas pour CVE‑2017‑8529 : il faut activer manuellement la FeatureControl FEATURE_ENABLE_PRINT_INFO_DISCLOSURE_FIX (iexplore.exe = 1, aussi sous WOW6432Node sur x64). Après redémarrage du navigateur et rescans, la vulnérabilité doit passer au vert. Conservez cette bascule dans vos politiques de conformité afin d’éviter toute régression.

Si vous devez justifier la démarche : la documentation Microsoft sur les builds Server 2016 confirme que les CU récents incluent le contenu des correctifs de 2017, et les bulletins des principaux éditeurs de scanners détaillent l’exigence de la clé Registre pour valider la mitigation côté IE. Cette combinaison “dernier CU + FeatureControl = 1” est la façon la plus fiable de clore la CVE dans des environnements encore dotés du moteur MSHTML.