Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

L’installeur d’Ubuntu Server enregistrait en clair une phrase de passe

L'installeur d'Ubuntu Server enregistrait en clair une phrase de passe

Le 13 mai 2020 à 09h39

Si vous activiez le chiffrement du stockage, la phrase de passe utilisée pour LUKS était enregistré en clair dans les logs. Une faille plutôt problématique, surtout pour un outil destiné aux entreprises.

Déclarée sous la référence CVE-2020-11932, elle est désormais corrigée, un patch étant disponible. Lorsque vous passez par la procédure d'installation « live », il sera appliqué automatiquement.

Le 13 mai 2020 à 09h39

Commentaires (13)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Dans quels logs ? Ils sont conservés après la fin de l’installation ou supprimés ?

votre avatar

dans /var/log/installer/

omg

votre avatar

Oh que oui ils sont conservés

votre avatar







John Shaft a écrit :



Oh que oui ils sont conservés





Le patch corrige une nouvelle installation, mais il se passe quoi pour les anciennes ? La passphrase est toujours là ? Il faut supprimer manuellement un fichier ?


votre avatar

A priori les logs déjà présents ne sont pas modifiés.



De toutes façons, le principe de précaution impose d’y passer un coup de lance-flamme préventif (et s’il ya vraiment besoin de les garder pour une raison X ou Y, chercher le mot de passe et y passer un coup de scalpel)

votre avatar

Dans un fichier accessible seulement après avoir tapé le mot de passe pour déchiffrer le disque ? <img data-src=" />

Bon c’est clair qu’en soit un mot de passe tapé en interractif n’a rien à foutre dans un log. J’espère que ce bug n’existe pas sur Debian…

votre avatar

Associé a une autre petite faille qui permet un accès distant donc sur un disque déjà déchiffré ca peut être dramatique.

votre avatar







Krogoth a écrit :



Associé a une autre petite faille qui permet un accès distant donc sur un disque déjà déchiffré ca peut être dramatique.






  Si tu obtiens un accès distant et donc très probablement une session, alors tu accèdes déjà au contenu déchiffré si c'est la partoche système (on ne parle pas d'un dossier spécifique ou d'un conteneur tiers qui lui serait chiffré à part).       


 C'est grave juste si tu accèdes uniquement au réseau et si (ça fait déjà pas mal de "si") les logs sont partagés sans protection, ce qui n'arrive que dans des cas délirants (même une install par défaut bloque cela).




Et vu le système dont on parle, peu de chances que ces logs soient envoyés sur un serveur d’agrégation genre&nbsp; Syslog ou stack ELK (là, ça serait rigolo ^^). 




 Aussi, le chiffrement est principalement intéressant quand tu perds ou te fais voler ta machine (peu de monde se fait réquisitionner son PC par le FBI ^^). Là, si les logs sont dans la partoche chiffrée, y'a pas de soucis :-).       


 Ransomeware ou spyware ? -&gt; On est dans le cas de la session déjà obtenue, donc chiffrement déjà passé.       







 Bref, ça n'est pas si grave que ça, ça va. Les mots font peur, on est à la limite du buzzword, mais quand on regarde vraiment de quoi il retourne, c'est rien.

votre avatar







John Shaft a écrit :



A priori les logs déjà présents ne sont pas modifiés.



De toutes façons, le principe de précaution impose d’y passer un coup de lance-flamme préventif (et s’il ya vraiment besoin de les garder pour une raison X ou Y, chercher le mot de passe et y passer un coup de scalpel)





Ce qui peut paraitre malin à faire c’est de changer la clé de déchiffrement “tout simplement”. Cela peut être bien de savoir faire, déjà d’une, et si c’était pas compromis pas de raison d’être inquiété



Dans les liens du brief il y a quelqu’un qui suggère ça avec une commande presque toute faite, si pas d’interface graphique



&nbsp;cryptsetup luksChangeKey &lt;target device&gt; -S &lt;target key slot number: 0..7&gt;



Par contre si je devais faire je ferais avec les pincettes et backup si possible, il y a une chance non négligeable de se coincer tout seul.



&nbsp;





grsbdl a écrit :



Et vu le système dont on parle, peu de chances que ces logs soient envoyés sur un serveur d’agrégation genre&nbsp; Syslog ou stack ELK (là, ça serait rigolo ^^).





Le figaro aurait pu logger ses passes de chiffrement du coup ? ^^



nextinpact.com Next INpact


votre avatar

Ubuntu… What else ? <img data-src=" />

votre avatar

Bah vu que c’est nous le root qui avons chiffré la machine, je vois plus ça comme un nouveau keepass… <img data-src=" />

Nan! j’déconne. <img data-src=" />

Du Ubuntu quoi !



Euh, chiffrer un serveur, c’est pas un truc de con à surtout ne pas faire ?

Je dis ça, je dis rien, mais quand on reboot le bousin, kicéki va taper le mdp luks hein ? <img data-src=" />

On n’a pas tous des iDrac activées sur nos matos, et dégainer la console VMware juste pour ça, spa très pratique… <img data-src=" />

votre avatar

Ce qui est marrant, c’est que je crois me souvenir que les premières Ubuntu avaient un pb similaire avec le mot de passe root à l’installation.



&nbsp;Il se retrouvait dans la log d’install. Mais ce n’est pas du vécu, à l’époque je crois que j’étais encore sur Mandriva. Depuis, même pas peur, je suis passé sur Kubuntu (donc Ubuntu).

votre avatar

Oui, changer les clés est une bonne idée. Si le problème ne touche que Ubuntu Server, version que j’imagine beaucoup installé sur des VMs, le snapshot qui va bien s’impose :)

L’installeur d’Ubuntu Server enregistrait en clair une phrase de passe

Fermer