Connexion
Abonnez-vous

Debian 12.7 et 11.11 disponibles, attention à Secure Boot

Le 02 septembre à 09h30

Les équipes de développement ont publié samedi deux bulletins pour avertir de la disponibilité des mises à jour pour Debian 12.7 (Bookworm, version actuelle) et 11.11 (Bullseye, version précédente). Comme toujours, si vos systèmes déjà en place appliquent les mises à jour régulièrement proposées, il n’y a rien à faire. Dans le cas contraire, elles vous attendent dans l’outil dédié ou en ligne de commande.

Dans les deux cas, il peut y avoir un problème avec Secure Boot :

« Les utilisateurs qui démarrent d'autres systèmes d'exploitation sur le même matériel, et qui ont activé Secure Boot, doivent savoir que shim 15.8 (inclus dans Debian 11.11 [ou 12.7, ndlr]) révoque les signatures des anciennes versions de shim dans le microprogramme UEFI. Cela peut empêcher l’amorce d'autres systèmes d'exploitation utilisant une version de shim antérieure à la 15.8. »

Il est donc conseillé de procéder avec soin dans ce type de situation. L’équipe recommande de désactiver temporairement Secure Boot avant de mettre à jour les autres systèmes d’exploitation éventuellement concernés.

Rappelons enfin que l’arrivée de ces versions d’entretien permet une mise à jour des images ISO d’installation. Depuis la page des téléchargements, les versions proposées sont donc les dernières. Il n’est toujours pas nécessaire de préparer un nouveau support d’installation, car les anciennes versions se mettront simplement à jour une fois le système en place.

Le 02 septembre à 09h30

Commentaires (7)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Le problème avec Secure Boot concerne autant Debian 12 que Debian 11. Utilisant Debian 12, j'ai justement été confronté à ce problème la semaine passée.
votre avatar
Oui pardon, je ne sais pas pourquoi j'ai limité le truc à la 11.11, j'ai fait la petite modif merci :)
votre avatar
Pas de secure-boot, pas de problèmes... Toujours commencé par désactiver ce truc avant de faire quoique ce soit d'autre sur une nouvelle machine.
votre avatar
Sur mon ordi perso (fait maison), j'ai aussi tendance a le désactiver, ayant très peu d'estime pour cet appareil et aucune donnée précieuse.

Cependant, Secure Boot contribue tout de même a fournir une protection contre les virus qui aiment se glisser dans le BIOS ou avant l'OS et sont donc particulièrement compliqués a dénicher, donc sur un portable j'aurai tendance a le garder.
votre avatar
Sauf que dans les faits, ce n'est pas une garantie.

Le problème de base, c'est surtout que depuis les tous débuts du PC Microsoft s'est appuyé sur des services du boot-loader pour beaucoup de choses: Aux débuts du PC, le moindre accès disque ou frappe clavier par exemple passait par ce qui était (mal) nommé interruptions (rien à voir avec la dénomination usuelle, c'était des services destinés à l'OS) BIOS. Tout ceci a fait le lit des virus dits "de secteur de boot".

Etudiant, j'avais d'ailleurs piqué les accès de quasiment toute l'école d'ingé après avoir chopé une telle vérole via des disquettes de feu "DP Tool Club" (qui envoyait freeware/sharewares sur disquette par la poste a l'époque ou l'internet balbutiait à la vitesse d'un minitel!)... et débusqué par le précurseur des antivirus par heuristique (l'alors excellent F-Prot), car pas de connection réseau=pas de base à jour: Analysé/détourné sur son mode d'install, j'en avais fait un keylogger qui casait sur une zone réservée des HDD les qq caractères qui suivaient des mots clef (époque largement pré-clicodrome-redmondien ayant abruti des générations ensuite, "informaticiens" compris) comme login/telnet: Username/passwd y étaient.

Désormais, l'UEFI a pris le relais avec les mêmes travers (avec les runtime services), la modularité en prime pour simplifier d'y coller des verrues. le x86 est un cas assez unique ou l'OS (Linux qui fait autrement partout ailleurs compris) ne découvre pas le matériel (à commencer par l'énumération PCIe).

Problème copié depuis par d'autres architectures (dont ARM), alors qu'un u-boot n'a pas ces travers... Mais les enclaves sécurisées pour gérer les clef et l'écriture de zones de boot flash sensibles, combiné à des firmwares (type ME, gérant les aspects pré-démarrage puis gestion alim/conso d'un processeur moderne) ayant la main avant tout le reste peuvent néanmoins le justifier même si la surface d'attaque n'est à la base pas vraiment la même et qu'aller toucher à cela sans se faire remarquer/créer des impacts fonctionnels sur un matériel spécifique ne serait déjà pas si simple.
votre avatar
et ça c'est sans compter des clés privées qui ont été commit dans un repo github public en 2022, ainsi que des clés de test utilisées en prod.
votre avatar
Cette mise à jour a aussi permis de rendre les ISO d'installation Debian à nouveau bootable sur les machines en dual boot avec Windows, depuis que Microsoft avait fait les mêmes mis à jour avec les mêmes restrictions sur l'UEFI mi-août. Debian était devenu non bootable sur les machines en dual boot avec Windows. Peut-être que Debian a tardé a appliqué cette mis à jour (6 mois), car les restrictions peuvent être effectivement problématiques.

Debian 12.7 et 11.11 disponibles, attention à Secure Boot

Fermer