Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !
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.

13 commentaires
Avatar de Jarodd INpactien
Avatar de JaroddJarodd- 13/05/20 à 08:53:46

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

Avatar de soupêtte Abonné
Avatar de soupêttesoupêtte- 13/05/20 à 08:58:40

dans /var/log/installer/
omg

Édité par soupêtte le 13/05/2020 à 08:59
Avatar de John Shaft Abonné
Avatar de John ShaftJohn Shaft- 13/05/20 à 10:18:15

Oh que oui ils sont conservés

Avatar de Jarodd INpactien
Avatar de JaroddJarodd- 13/05/20 à 10:27:39

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 ?

Édité par Jarodd le 13/05/2020 à 10:27
Avatar de John Shaft Abonné
Avatar de John ShaftJohn Shaft- 13/05/20 à 10:35:17

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)

Édité par John Shaft le 13/05/2020 à 10:35
Avatar de Obidoub Abonné
Avatar de ObidoubObidoub- 13/05/20 à 11:15:40

Dans un fichier accessible seulement après avoir tapé le mot de passe pour déchiffrer le disque ? :D
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...

Avatar de Krogoth Abonné
Avatar de KrogothKrogoth- 13/05/20 à 12:14:39

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

Avatar de grsbdl INpactien
Avatar de grsbdlgrsbdl- 13/05/20 à 13:05:51

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  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 ? -> 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.
Édité par grsbdl le 13/05/2020 à 13:09
Avatar de Methio INpactien
Avatar de MethioMethio- 13/05/20 à 19:16:04

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

 cryptsetup luksChangeKey <target device> -S <target key slot number: 0..7>

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.

 

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

Avatar de Ricard INpactien
Avatar de RicardRicard- 13/05/20 à 19:29:23

Ubuntu... What else ? :fumer:

Il n'est plus possible de commenter cette actualité.
Page 1 / 2