Connexion Premium

Microsoft diffuse en urgence un patch pour MSMQ sur Windows 10

Windows 10 n’a officiellement plus de support technique depuis le 14 octobre dernier. Dans l’ensemble des marchés, il est d’ordinaire possible de payer pour obtenir une année de support supplémentaire. Ce programme, nommé Extended Security Updates (ESU), est cependant gratuit en Europe. Il est limité à la première année et prendra fin (en théorie) en octobre 2026.

Dans le cadre de cette extension, des correctifs sont publiés pour les failles importantes ou critiques. Or, le dernier « Patch Tuesday » comportait une mise à jour spécifique, KB5071546, qui a entrainé de sérieux problèmes pour la fonction Message Queuing (MSMQ). Son installation a ainsi entrainé un arrêt de la fonction sur les machines Windows 10, Windows Server 2019 et Windows Server 2016.

Microsoft a rapidement publié une fiche technique pour résumer les symptômes : les files d’attente MSMQ deviennent inactives, les sites IIS ne fonctionnent plus et affichent des erreurs « Ressources insuffisantes pour effectuer l’opération », les applications ne peuvent plus écrire dans les files d’attente, des journaux (logs) affichent de faux messages « Il n’y a pas assez d’espace disque ou de mémoire », etc.

L’éditeur en profitait pour indiquer la source du souci : « Ce problème est causé par les récents changements introduits dans le modèle de sécurité MSMQ et les permissions NTFS sur le dossier C:\Windows\System32\MSMQ\storage. Les utilisateurs MSMQ doivent désormais accéder en écriture à ce dossier, qui est normalement réservé aux administrateurs. En conséquence, les tentatives d’envoi de messages via les API MSMQ peuvent échouer avec des erreurs de ressources. »

Dans la nuit du 18 au 19 décembre, Microsoft a donc publié en urgence un patch pour rétablir la fonction. L’entreprise ajoute d’ailleurs que ce problème peut aussi affecter un « environnement MSMQ clusterisé sous charge ». Les administrateurs sont invités à diffuser la mise à jour dans les parcs concernés.

Commentaires (13)

votre avatar
Autant je peux comprendre que certains bogues passent sous les radars quand ils ne sont pas systématiques ou ont une composante "aléatoire" (car dépend d'une configuration spécifique par exemple), autant j'ai du mal à concevoir qu'un problème comme celui-ci ait pu passer inaperçu avant déploiement.

Le véritable problème est là à mes yeux !!
votre avatar
La méthode MS pour se faire avoir à chaque fois tient en 4 mots : tester, c'est douter.
votre avatar
En tout cas, maintenant, je doute qu'ils testent !
votre avatar
Ou ils testent tout avec des droits administrateurs !
votre avatar
En cas de doute, you need to be root.
votre avatar
Et uniquement en langue anglaise.
votre avatar
La prod est la meilleure des qualifs on a toujours dit !
votre avatar
Et compiler c'est tester :)
votre avatar
Les patch sont maintenant codés par CoPilot ! Donc sans surprise, les tests sont bons (faits aussi par CoPilot) .
votre avatar
Vu le service touché, je me demandais en quoi ça pouvait concerner Windows 10 et leur fiche technique me confirme que c'est très peu probable :
Individuals using Windows Home or Pro editions on personal devices are very unlikely to experience this issue. This issue primarily affects enterprise or managed IT environments.
Titrer sur Windows 10 me semble putaclic inutile.
votre avatar
Et est-ce que Microsoft compte résoudre le problème de bitlocker qui me demande à chaque démarrage le code de récupération ?
C'est plus que casse pieds (Windows 10 + Grub).
votre avatar
La réponse est dans la question : sur Windows 10 seuls les bugs de sécurité sont corrigés et à condition de bénéficier du support Extended Security Update.

Ce bug n'étant pas un bug de sécurité (même s'il est connexe) ne sera jamais corrigé sur Windows 10.
votre avatar
C'est vraiment un bogue, ou c'est que Windows considère la chaine de boot comme altérée et donc refuse de récupérer la clé depuis le TPM ?