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.
![[Édito] Apple entre greenwashing et renouvellement à marche forcée](https://next.ink/wp-content/uploads/2024/09/Apple_greenwashing-510x247.webp "[Édito] Apple entre greenwashing et renouvellement à marche forcée")
Commentaires (7)
#1
#1.1
#2
#2.1
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.
#2.2
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.
#2.3
#3