298 private links
Ce qu'il y a de bien pratique avec la distribution GNU/Linux Gentoo, c'est qu'elle nous fait découvrir des mécanismes cachés du système d'exploitation ; et récemment, ce fut encore le cas quand je voyais dans certains paquets le "USE flag" intitulé "pic", qui est donc l'acronyme[1] de “Position Independent Code”.
Dans cet article, il est ainsi question du “Position Independent Code” dans les bibliothèques partagées.
Du peu que j'ai pu comprendre (car n'ayant pas fini de lire cet article qui me semble compliqué), il s'agit d'un mécanisme de protection du code d'exécution des binaires ELF[2] en rendant les positions des liens des processus dans la mémoire de façon aléatoire, ce qui a pour but d'empêcher un programme malveillant d'accès à des zones de données, pour y copier ou manipuler des données.
Bref, ce n'est pas à la portée de tous, mais ça permet de mieux comprendre le fonctionnement d'un système GNU/Linux.
[1] un acronyme est un sigle qui se lit comme un mot https://fr.wikipedia.org/wiki/Acronymie
[2] ELF pour “Executable and Linkable Format”, le format des binaires sous GNU/Linux pour les architectures x86 https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
EDIT 2015-03-01: D'autres infos :
- le man de gcc(1) (descriptions de -fPIC et -fPIE)
- encyclopédie Wikipedia https://en.wikipedia.org/wiki/Position-independent_code (anglais)
- la distribution Red Hat https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/
Oh ! Un TRNG (True Random Numbers Generator) libre, sous forme de clef USB, pour 25$ (soient 22,15€).
Ce périphérique est libre, dans le sens où les pilotes sont aussi libres, et les plans pour monter son propre périphérique aussi. Il fonctionne à base d'un « générateur de sons ».
Une nouvelle faille dans les systèmes Unix a été détectée.
cette faille, nommée GHOST, se situe dans la bibliothèque glibc - un composant essentiel aux systèmes GNU/Linux - à cause d'un appel de la fonction oboslète gethostname() (dont son nom), qui permet de faire un dépassement de tampon (buffer overflow).
Cette faille est en principe moins touchée pour les version supérieur ou égale à la version 2.18, mais il est conseillé de mettre à jour, pour corriger pleinement cette faille (c.f le communiqué sur la liste FRsAG).
Voir aussi :
http://www.frsag.org/pipermail/frsag/2015-January/005722.html (français)
https://www.nextinpact.com/news/92886-ghost-nouvelle-faille-critique-qui-fait-trembler-linux.htm (français)
https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability (anglais)
Note : dans la section 4 de cette page, il y a un code à compiler soit même :
- copiez simplement la commande qui contient la ligne "cat > GHOST.c << EOF" et finit par "EOF",
- faites "gcc -o GHOST GHOST.c" puis "./GHOST",
- regardez le résultat, pour savoir si vous êtes vulnérable à cette faille ou non.
Encore une nouvelle faille découverte dans le monde de la cryptographie et des communications, qui touche SSLv3, un protocole de chiffrement de communications, en principe obsolète mais encore utilisé lors des échanges avec HTTPS avec d'anciens navigateurs ou serveurs web.
Cette faille, nommée POODLE ("Padding Oracle On Downgraded Legacy Encryption") ne touche pas une implémentation, mais le protocole SSLv3 lui-même, protocole créé en 1996, et rendu obsolète par TLS en 1999.
Cette faille est dû au fait que certaines informations lors des échanges ne sont pas définies, permettant à des personnes malveillantes de manipuler et de décrypter les données (« décrypter » = « déchiffrer sans la clef de déchiffrage »).
Alors, pas trop de soucis à ce faire, il existe le protocole TLS, qui le remplace et le surpasse même, et ce depuis sa création en 1999. Alors, pourquoi avons-nous encore SSLv3 ? En parti pour le support de Internet Explorer 6, qui ne supporte pas au dessus de SSLv3.
En prime, glaner dans les docs de Mozilla, voici comment faire pour forcer le support TLS dans le navigateur web Mozilla Firefox :
- tapez dans votre barre d'adresse "about:config",
- cliquez sur "promis, je ferai attention",
- cherchez l'entrée "security.tls.version.min",
- modifiez sa valeur (double-clic, ou clique-droit), et remplacez la valeur par défaut "0" par "1",
- voilà, les modifications sont enregistrées, vous pouvez donc vérifiez en testant sur l'adresse https://www.poodletest.com/
D'autres sources, en français :
https://www.nextinpact.com/news/90427-la-faille-poodle-sslv3-permet-decrypter-donnees-sur-connexion.htm
https://www.numerama.com/magazine/30934-poodle-google-devoile-une-faille-critique-dans-ssl-30.html
Oh bon sang ! C'est quoi cette horreur !?
ça lit la piste magnétique (en France, ça fait un moment qu'on a des cartes avec puces...), ça encode en son (wtf?), ça passe par la prise jack micro (wtf2?), et enfin, ça passe par Amazon Local Register, le service bancaire d'Amazon (WTF3!?).
Question sécurité, c'est une hécatombe totale : le son peut très bien être copié par un autre processus, et vu qu'il s'agit de la piste magnétique, c'est donc une donnée "unique", qui se copie. Même encodé, j'ai un doute, vu qu'un malware installé sur le même appareil peut très bien découvrit la clef privée, toujours en écoutant sur la sortie audio.
Et ne parlons pas des services bancaires d'Amazon ... Déjà, toutes vos transactions passeront par leurs serveurs, serveurs appartenant à une société américaine... Et ce tarif de 2,5 % ... wow, tu parles d'un service pour les petits marchands... Comme si les autres services de ce genre vont se laisser faire aussi, les banques rajouteront des frais, ça ne fera pas un pli.
Bref, une très mauvaise idée.
Quelques instructions à garder, lorsque l'on veut éviter de voir certaines données stockées en mémoire vive se retrouver sur la swap.
Ce tutoriel permet de connaître et de mettre en place d'autres moyens pour déployer sa clef publique, en plus des traditionnelles méthodes avec les serveurs de clefs, ou le fichier sur votre serveur HTTP.
Ainsi, j'ai pu mettre en place ce système, en utilisant la méthode de téléchargement par URL.
Il suffit donc de rajouter l'option "auto-key-locate pka" dans votre fichier de configuration (~/.gnupg/gpg.conf), et ainsi, en m'écrivant un courriel (si votre client courriels le permet), ma clef publique sera téléchargée.
Pour un peu plus de détails, voici un petit résumé, basé sur mes connaissances et sur l'ensemble des sources que j'ai lues :
« Heartbleed » est une faille concernant un module d'OpenSSL nommé « HeartBeat », découverte ce lundi 7 avril 2014 ; elle touche certaines versions d'OpenSSL, la branche 1.0.1a à 1.0.1f ainsi que la béta 1.0.2 (1.0.1g corrige cette faille, ainsi que la prochaine monture de la béta).
Toutefois, OpenSSL n'est pas concerné pour les versions en 0.9 ou en 1.0.0, ni les systèmes qui n'ont pas ce module de compilé (sous Gentoo, le module HeartBeat est désactivable).
Cette faille s'inscrit au niveau de TLS (“Transport Layer Security” https://en.wikipedia.org/wiki/Transport_Layer_Security), car le rôle de HeartBeat est de maintenir un “keepalive” au niveau de la session TLS ; ce keepalive permet en autre d'éviter de devoir refaire une renégociation avec une « poignée de mains » (“handshake”), qui est peut être assez lourd en terme de quantité de données échangées et aussi en calculs cryptographiques.
Cette faille permet donc de récupérer une petite quantité d'informations, jusqu'à 64ko de mémoire avec une simple requête, ce qui permet donc théoriquement de récupérer les clefs privées stockées en mémoire et ainsi déchiffrer les communications. D'autres informations peuvent fuiter, comme directement des mots de passe, ou des messages, c'est bien pour ces raisons qu'il est conseillé de mettre à jour vos mots de passe, et pour les administrateurs des services, de générer de nouvelles clefs de chiffrement.
Or, pourquoi autant de serveurs fonctionnent-elles avec ces versions 1.0.1 de OpenSSL ? Car ces versions ont d'implémentée la version 1.2 de TLS. Et vu qu'OpenSSL est très répandu dans le monde du logiciel libre et des serveurs, la faille est ainsi très répandue – on parlerait de deux tiers des services web.
Mais qu'en est-ils des autres services ?
Oui, d'autres services se basant sur l'implémentation de TLS d'OpenSSL, comme emails, XMPP, etc. font du TLS. Cependant, OpenSSH n'utilise pas le protocole TLS pour échanger des données, mais son propre protocole ; OpenSSH se base sur OpenSSL, pas pour le TLS, mais pour les algorithmes de chiffrement.
Comme le dit Bruce Schneier : “"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.”
https://www.schneier.com/blog/archives/2014/04/heartbleed.html
Pour plus de lectures, quelques infos sur la normalisation de l'extension HeartBeat dans la RFC 6520 https://www.bortzmeyer.org/6520.html, des infos techniques sur la faille http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html, une critique de Theo de Raadt sur OpenSSL http://thread.gmane.org/gmane.os.openbsd.misc/211952/focus=211963, encore là sur Numérama http://www.numerama.com/magazine/29026-heartbleed-que-faut-il-craindre-de-cette-faille-openssl.html et sur PCINpact http://www.pcinpact.com/news/86941-heartbleed-openssl-et-question-securite-expliques-simplement.htm et enfin l'info depuis le ministère de la défense. http://cert.ssi.gouv.fr/site/CERTFR-2014-AVI-156/
Au courant depuis lundi soir, Heartbleed est vraiment une faille d'une importance catastrophique.
Plus d'infos https://links.thican.net/?k_fRjw
Très bonne remarque au sujet de GnuPG et des méta-données.
En résumé, utiliser l'option "throw-keyids" par défaut n'est pas une bonne idée, mais il est tout à fait possible de l'utiliser ponctuellement, en ligne de commande avec "--throw-keyids"
SÉRIEUX !!!???
Là, c'est le niveau absolu du petit apprenti sorcier …
Une voiture de 2005 (dans l'exemple, une Toyota Camry) avec plus de 81 514 (!) violations suivant la MISRA https://en.wikipedia.org/wiki/MISRA de 2004 !
Lisez donc la dépêche, il y a des erreurs qui sont effarantes.
J'étais effrayé du futur (https://links.thican.net/?lX3BNg), mais je me trompais : nous y sommes déjà !
Voitures toujours plus connectées, bourrées d'électronique et de logiciels, les mêmes que l'on trouve sur nos ordinateurs, voilà un bien sombre présage ; et pourtant, ce futur est déjà là.
Pourquoi se méfier ? Car bientôt (ou déjà ?), les virus vont mettre en danger la vie des usagers.
Il faudra bien choisir sa voiture dès aujourd'hui, question de survie.
Un article au sujet de la génération pseudo-aléatoire.
Un sujet qui revient souvent, le stockage des mots de passe en BDD.
Note : ceux qui parlent de chiffrement pour le stockage n'ont pas compris grand chose à ce sujet.
Savez-vous que les scripts Bash ne s'exécutent pas s'ils sont le bit SUID d'actif ?
Comme l'explique cet article, Bash de sa propre initiative perd les droits root, et ceci pour éviter de créer des failles.
Cela peut paraître évident pourquoi, mais il est étonnant de voir les angles d'attaques possibles pour acquérir les droits root à partir d'un simple script Bash avec le SUID.
La sécurité est un domaine très vaste.
Pour ceux qui sont intéressés par la version Hardened de la distribution Gentoo, voici des infos sur les options liées au kernel.
(J'avoue que c'est hors de mon niveau, mais soit, ça peut être intéressant)
Livre en anglais sur la sécurité des applications.
Via FRnOG : http://www.mail-archive.com/frnog@frnog.org/msg26084.html
Sauvegarde : http://thican.net/~thican/Peter_Gutmann-Engineering_Security-2013.pdf
Une nouvelle application sous Android pour faire de l'authentification forte avec de l'OTP (One Time Password), comme Google Authenticator https://links.thican.net/?6mMMPw, mais sans le côté Google de la chose, et cette application ne requiert pas d'accès au réseau, contrairement à celle de Google.
Et le logiciel a une licence en GPLv3. :-)