| |
|
|
| lun |
mar |
mer |
jeu |
ven |
sam |
dim |
 |
|
|
|
1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | |
|
|
|
|
Faille de sécurité chez GNU/Linux Debian |
| Actualité publiée par CaSa le Vendredi 16 Mai 2008 |
|
Une importante faille de sécurité a été découverte dans la distribution DEBIAN il y a quelques jours sur un composant essentiel de GNU/Linux. Cette faille affecte la génération aléatoire de paires de clef SSH, une procédure utilisée pour mettre en place des communications sécurisées entre machines (linux/linux, linux/windows,...), des VPN, tout ceci à l’aide de systèmes d’authentifications automatisées.
L’introduction d’un bug dans le code de "génération aléatoire" datait visiblement de 2006 et impactait le nombre possible des clefs pouvant être générées (théoriquement par millions) en un nombre fini de quelques centaines de milliers.
Un important problème donc car les mesures de sécurités reposant sur un échange de clefs SSH ne résistaient plus à une attaque de type "brute force".
Les mises à jour (paquets openssh) ont immédiatement été déployées et disponibles sur les serveurs. Comme Debian est la base de plusieurs distributions dérivées, ces dernières sont aussi touchées et sont mises à jour de fait (Ubunutu, Mepis, Knoppix, ...).
Outre ces corrections à faire sans tarder sur les serveurs sensibles utilisant ces procédures, il faut également regénérer les paires de clefs et remettre en place les clefs privées/publiques aux bons endroits car les anciennes ne seront plus valides et normalement blacklistées. Du travail en perspective pour tous les administrateurs de systèmes GNU/Linux.
Au-delà de l’aspect technique, espérons que la communauté Debian de souffrira pas trop de cette découverte et saura gérer les critiques à son égard. Effectivement c’est sans aucun doute une bonne occasion pour ses détracteurs de remettre en cause les qualités reconnues d’une des distributions les plus utilisées en serveurs de productions GNU/Linux.
<< Source Linuxfr.org >> |
|
|
|
Actualité précédente |
Actualité suivante |
|
|
|
| Par
CaSa le Dimanche 18 Mai 2008 à 18:40 |
|
Pour information, certaines applications Linux se servent d'une paire de clefs SSH fixe et par défaut dans leur installation de base. C'est le cas de NXSERVEUR de NOMACHINE.
Suite à l'introduction d'une liste de blacklistage de clefs, il arrive donc hélas que la paire de clef NX en configuration par défaut ne peut plus fonctionner. C'est bien entendu détournable, mais assez pénalisant pour l'administration puisqu'il faut générer une paire de clefs perso et écraser les clefs SSH par défaut du serveur NX et des clients.
A faire :
=> sur le serveur :
1 - générer une paire de clef dsa (id_dsa et id_dsa.pub) et les copier dans /var/lib/nxserver/home/.ssh
2 - remplacer le contenu du fichier /var/lib/nxserver/home/.ssh/authorized_keys2 par celui de id_dsa.pub (clef publique)
3 - remplacer le contenu du fichier /var/lib/nxserver/home/.ssh/client.id_dsa.key par celui de id_dsa (clef privée)
4 - éditer le fichier de clef publique (authorized_keys2) et rajouter juste avant le bloc "ssh-dss..." les mentions : no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/nx/nxserver"
(pour obtenir donc no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/nx/nxserver" ssh-dss...)
=> sur le client, dans la configuration de nxclient :
1 - lancez nxclient et allez dans configuration
2 - éditer le fichier KEY, supprimez la clef NOMACHINE (commençant par MIIBuwIBAA...) et mettez à la place le contenu de clef privée fichier "client.id_dsa.key")
Il faut hélas changer la clef privée sur tous les clients NXCLIENT. C'est pénalisant mais on positivera en disant que ça renforce la sécurité puisque ce n'est plus une clef NOMACHINE par défaut. |
|
|
 |
| Par
etienne2000 le Dimanche 18 Mai 2008 à 18:46 |
|
es-ce que Unbuntu en fait partie? |
|
|
|
| Par
CaSa le Dimanche 18 Mai 2008 à 19:10 |
|
|
| Par
Skynet le Dimanche 18 Mai 2008 à 21:59 |
|
|
| Par
CaSa le Lundi 19 Mai 2008 à 09:54 |
|
Citation:
| @CaSa : Ca aurait pu poser problème sur les transactions bancaires par exemple ? |
|
Je ne sais pas, ça dépendait du système employé c'est vraiment spécifique à Debian et à l'utilisation de la bibliothèque OpenSSL. Cela dit si tu parles des transactions bancaires ponctuelles, les paires de clefs ne sont générées que pour servir provisoirement, je ne pense pas qu'on puisse détourner une connexion dans ce laps de temps très court.
Il y a des systèmes qui ne se servent pas de OpenSSL pour la gnéération de paires de clefs et qui n'ont donc pas été touchés par le bug. C'est le cas de GPG et des générations de clefs de chiffrage/signatures mail ou des signatures de paquets programmes.
Heureusement d'ailleurs, la galère mondiale s'il avait fallu également regénérer les clefs mails.  |
|
|
|
| Par
etienne2000 le Lundi 19 Mai 2008 à 13:57 |
|
Ah ok. de toute façon je n'utilise pas Ubuntu pour les transactions bancaires donc a ce niveau la c'est bon  |
|
|
|
| Par
Skynet le Lundi 19 Mai 2008 à 17:40 |
|
Ok,
donc au final, et vu que c'est corrigé, personne n'a recensé de problème
suite à cette faille apparemment...
C'était simplement de la curiosité pour ma question, puisque mes paiements
ont été faits sur d'autres distributions d'une branche différente.
Mais bon, vu que j'aime bien Bubuntu, SymphonyOS, Linux Mint et PureOS, je note l'info.
Les utilisateurs des EeePC ont intérêt à faire leur mise à jour aussi.
C'est sans oublier la célèbre distribution : Damn Small Linux |
|
|
|
|
Autres
Logiciels
Linux
Windows
PC-InfoPratique
Faites le plein de logiciels gratuits sur AV...
Voir toutes les actualités
