Ce qui est démontré dans le cas Debian c'est qu'il à fallu au moins 2 failles de sécurité pour passer root.
Si les éléments pour comprendre l'usurpation des privilèges de root manquent actuellement, ce seul défaut n'aurait pas suffit à quelqu'un d'extérieur au projet pour exploiter cette faille (Je fais l'hypothèse que tous les mainteneurs Debian sont gentils.).
Il a donc fallu exploiter en premier lieu un autre défaut pour se faire passer pour un utilisateur normal d'une machine Debian.
Je regrette le manque d'explication sur ce préalable, et je vais tenter de proposer plusieurs hypothèses naïves que je soumet à votre sagacité.
Tout d'abord il faut envisagé les cas non techniques. Je n'en vois qu'un. C'est le cas ou le pirate a regardé par dessus l'épaule d'un mainteneur Debian au moment où il se loggait sur une machine Debian (cas 0).
Les cas techniques que j'entrevois sont les suivants :
1 - espionnage de l'entrée du mot de passe au clavier
2 - exploitation d'une faille dans SSH/OpenSSH permettant de décrypter le mot de passe envoyé
3 - vol d'une la clé privé OpenSSH
4 - autres exploitations de faille SSH permettant de se passer d'une authentification
5 - exploitation d'une faille GPG permettant de décrypter un message et interception d'un mail de demande de changement de mot de passe
6 - interception d'une transaction SSL de demande de changement de mot de passe
7 - espionnage de la page/mémoire du navigateur lors du changement par un mainteneur Debian de ses info personnelles sur le site db.debian.org.
Dans les cas 0,1,3 et 7 il faut probablement que le pirate soit root pour que cela soit possible, et donc qu'il soit administrateur de la machine ou qui ai usurpé les droits de root sur cette machine également.
Il me semble que l'on peu raisonnablement se prémunir contre ces 4 cas par l'application d'une politique de sécurité rigoureuse mais malheureusement contraignante, qu'il risque d'être difficile à imposer à une communauté de bénévoles.
Par contre pour les cas restants, la seule solution que j'envisage est de rechercher les failles et de se passer des services inutiles.
# Il y a au moins 2 failles à prendre en compte
Posté par Jetto . En réponse à la dépêche Du nouveau sur les serveurs Debian compromis. Évalué à 4.
Si les éléments pour comprendre l'usurpation des privilèges de root manquent actuellement, ce seul défaut n'aurait pas suffit à quelqu'un d'extérieur au projet pour exploiter cette faille (Je fais l'hypothèse que tous les mainteneurs Debian sont gentils.).
Il a donc fallu exploiter en premier lieu un autre défaut pour se faire passer pour un utilisateur normal d'une machine Debian.
Je regrette le manque d'explication sur ce préalable, et je vais tenter de proposer plusieurs hypothèses naïves que je soumet à votre sagacité.
Tout d'abord il faut envisagé les cas non techniques. Je n'en vois qu'un. C'est le cas ou le pirate a regardé par dessus l'épaule d'un mainteneur Debian au moment où il se loggait sur une machine Debian (cas 0).
Les cas techniques que j'entrevois sont les suivants :
1 - espionnage de l'entrée du mot de passe au clavier
2 - exploitation d'une faille dans SSH/OpenSSH permettant de décrypter le mot de passe envoyé
3 - vol d'une la clé privé OpenSSH
4 - autres exploitations de faille SSH permettant de se passer d'une authentification
5 - exploitation d'une faille GPG permettant de décrypter un message et interception d'un mail de demande de changement de mot de passe
6 - interception d'une transaction SSL de demande de changement de mot de passe
7 - espionnage de la page/mémoire du navigateur lors du changement par un mainteneur Debian de ses info personnelles sur le site db.debian.org.
Dans les cas 0,1,3 et 7 il faut probablement que le pirate soit root pour que cela soit possible, et donc qu'il soit administrateur de la machine ou qui ai usurpé les droits de root sur cette machine également.
Il me semble que l'on peu raisonnablement se prémunir contre ces 4 cas par l'application d'une politique de sécurité rigoureuse mais malheureusement contraignante, qu'il risque d'être difficile à imposer à une communauté de bénévoles.
Par contre pour les cas restants, la seule solution que j'envisage est de rechercher les failles et de se passer des services inutiles.
Vous avez d'autres idées ?