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

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

Par Sébastien Gavois

Le 13 Mai 2020 à 09h39
Logiciel
1 min 13

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

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.

Commentaires (13)


Jarodd Abonné
Le 13/05/2020 à 08h53

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


cauzik Abonné
Le 13/05/2020 à 08h58

dans /var/log/installer/

omg


John Shaft Abonné
Le 13/05/2020 à 10h18

Oh que oui ils sont conservés


Jarodd Abonné
Le 13/05/2020 à 10h27







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 ?



John Shaft Abonné
Le 13/05/2020 à 10h35

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)


Obidoub
Le 13/05/2020 à 11h15

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…


Krogoth
Le 13/05/2020 à 12h14

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


grsbdl Abonné
Le 13/05/2020 à 13h05







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.


Methio Abonné
Le 13/05/2020 à 19h16







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 ? ^^



https://www.nextinpact.com/brief/fuite-de-8-to–dont-des-donnees-personnelles–a…



Ricard
Le 13/05/2020 à 19h29

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


domFreedom
Le 13/05/2020 à 21h20

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=" />


Chocolat-du-mendiant Abonné
Le 13/05/2020 à 22h38

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).


John Shaft Abonné
Le 14/05/2020 à 13h54

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 :)


Fermer