All posts by admin

Les limites de l’open source

ATTENTION : cet article est destiné aux informaticiens ou, à la rigueur, aux personnes vraiment très curieuses à propos de la lutte contre les pirates.

Cette histoire commence par l’observation de messages inhabituels dans les journaux système :

Aug 31 08:43:31 host sshd[14231]: dispatch_protocol_error: type 90 seq 5 [preauth]
Aug 31 08:44:01 host sshd[14231]: dispatch_protocol_error: type 96 seq 6 [preauth]
Aug 31 08:44:01 host sshd[14231]: dispatch_protocol_error: type 97 seq 7 [preauth]

En première approche, l’instinct d’administrateur système suggère d’ignorer ces messages. Ce sera effectivement la conclusion de l’analyse qu’ils motivèrent. Si vous êtes là juste pour savoir ce qu’il faut en faire, la lecture de la suite est optionnelle.

Un 31 août c’est encore un peu les vacances. On a donc un peu plus de temps et on aimerait bien savoir à quoi correspondent ces mystérieux “type 90, 96 ou 97” pour lesquels il y a une “dispatch_protocol_error”.

A l’intention du profane, il est utile de préciser que ces messages d’erreur émanent du démon sshd. Pour faire simple, un démon est un processus système qui tourne en tâche de fond. Et le processus sshd est celui qui gère les connexions à distance. Dans le contexte de l’administration de serveur c’est à la fois un dispositif essentiel et incontournable et, en conséquence, la principale cible des pirates.

Une recherche méthodique sur Internet à propos de ces mystérieux messages d’erreur n’aboutit à aucun résultat probant. Il faut donc aller à la source de l’information : les sources d’OpenSSH.

On obtient ainsi plus de 740 fichiers qui totalisent plus de 200 000 lignes de code… la recherche de l’information convoitée est un véritable jeu de piste.

dispatch.c

L’instruction qui produit le message d’erreur “dispatch_protocol_error: type t seq n” est facile à trouver dans la fonction dispatch_protocol_error().

auth2.c

Cependant, cette fonction n’est appelée nulle part directement mais un pointeur sur cette fonction est utilisée dans l’instruction ssh_dispatch_init(ssh, &dispatch_protocol_error).

dispatch.c

En examinant de plus près ce que la fonction ssh_dispatch_init() fait de son paramètre dflt on découvre que le pointeur sur la fonction responsable des mystérieux messages est mémorisé dans la structure ssh->dispatch[i].

packet.c

En cherchant l’usage de cette information on apprend que l’appel de la fonction se fait dans ssh_dispatch_run() par l’instruction (*ssh->dispatch[type])(type, seqnr, ssh). A ce stade type est déjà défini auparavant dans la même fonction par l’une des instruction ssh_packet_read_seqnr(ssh, &type, &seqnr) ou ssh_packet_read_poll_seqnr(ssh, &type, &seqnr).

dispatch.c

En étudiant le code de ces deux fonctions on en déduit que le fameux type est défini dans la fonction ssh_packet_read_poll2(). Il y est d’abord initialisé à la valeur SSH_MSG_NONE puis renseigné par sshbuf_get_u8(state->incoming_packet, typep).

ssh2.h

Ah, là on tient un indice intéressant : SSH_MSG_NONE qui mène à la mine d’informations recherchée :

/* channel related messages */ 

#define SSH2_MSG_CHANNEL_OPEN              90
#define SSH2_MSG_CHANNEL_OPEN_CONFIRMATION 91
#define SSH2_MSG_CHANNEL_OPEN_FAILURE      92
#define SSH2_MSG_CHANNEL_WINDOW_ADJUST     93
#define SSH2_MSG_CHANNEL_DATA              94
#define SSH2_MSG_CHANNEL_EXTENDED_DATA     95
#define SSH2_MSG_CHANNEL_EOF               96
#define SSH2_MSG_CHANNEL_CLOSE             97
#define SSH2_MSG_CHANNEL_REQUEST           98
#define SSH2_MSG_CHANNEL_SUCCESS           99
#define SSH2_MSG_CHANNEL_FAILURE           100

Donc ces mystérieux “type 90, 96 ou 97” pour lesquels il y a une “dispatch_protocol_error” correspondent à :

SSH2_MSG_CHANNEL_OPEN
SSH2_MSG_CHANNEL_EOF
SSH2_MSG_CHANNEL_CLOSE

Et là c’est beaucoup plus clair !

Il s’agit vraisemblablement de tentatives de connexion faites avec des paquets incohérents. Une telle approche évoque une technique similaire à celle mise en œuvre pour exploiter la faille CVE-2018-15473 : on génère des erreurs volontairement pour glaner indirectement des informations sur la cible.

Pour ce qui concerne les dispositions à prendre pour contrer une nouvelle forme d’attaque, il n’y a rien de plus à faire pour consolider les défenses du serveur que ce qui est déjà fait.

Tout ce qui précède n’est en fait qu’un préambule au véritable sujet de cet article : une réflexion sur l’open source.

Tout d’abord cela illustre directement la réflexion de l’article “WHAT IS BETTER THAN OPEN SOURCE?” : une documentation concise serait bien plus utile en complément des fichiers sources ; elle permettrait d’éviter un reverse engineering laborieux pour décoder les sens cachés de message d’erreur.

Mais surtout, l’analyse faite à l’occasion de cette recherche sur un élément essentiel et crucial des serveurs exposés sur Internet donne le frisson.

On y découvre un style de programmation artificiellement compliqué. Par exemple : mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d’appeler tout simplement la fonction elle-même ? Le reste est à l’avenant, avec notamment un recours avide aux pointeurs, une fonctionnalité très puissante lorsqu’elle est bien employée mais une source redoutable d’erreurs.

Cela a sans doute peu d’impact sur les performances mais aboutit à un code difficile à comprendre et donc à la fois propice aux bugs et difficile à maintenir ;  un véritable terreau pour les failles de sécurité et un terrain très favorable aux portes dérobées.

On aboutit au résultat opposé à celui recherché par l’open source !

Visibilité inattendue de numerunique

Comme l’atteste la photo ci-dessus (où l’on aperçoit le logo de numerunique à la Fondation Serralves, à Porto), la visibilité de numerunique s’étend bien au delà de son périmètre originel.

Que numerunique soit visible à l’international est déjà remarquable mais qu’il le soit aussi dans le domaine de l’art contemporain est tout à fait inattendu.

En l’occurrence, c’est son logo qui lui a valu l’enthousiasme spontané d’amateurs d’art érudits qui ont eu l’idée bienvenue d’afficher numerunique dans un haut lieu de l’art contemporain.

L’idée serait-elle supérieure à sa réalisation ?

Le rangement des archives de numerunique a sorti de l’ombre un document qui invite à la réflexion. C’est ni plus ni moins que le manuel de référence du premier serveur web de l’histoire !

Il date de mai 1994 ; il a donc tout juste plus de 24 ans. A l’époque c’était simplement un document de travail, à la pointe de la technologie. Aujourd’hui, à l’échelle de temps de l’informatique, il tient davantage du fossile préhistorique que du manuel de référence. Il est numérisé et partagé ici : httpd1994.

Un détail attire l’attention : il a été écrit par Ari Luotonen et Tim Berners-Lee.

Une recherche rapide sur Internet révèle que ce serait Ari, alors étudiant au CERN, qui aurait réalisé cet élément crucial de l’idée de Tim à qui est pourtant universellement (et à juste titre) attribué l’invention du Word Wild Web.

Ari, comme la plupart de ceux qui ont contribué à la concrétisation de l’idée de Tim, a complètement disparu de l’histoire. Pour celle-ci c’est donc incontestablement l’idée qui prime sur sa réalisation.

Pourtant, avoir une idée c’est très facile mais la réaliser beaucoup moins ! Et une idée “en l’air” c’est juste rien. C’est sa réalisation qui lui donne tout son intérêt.

Chez numerunique, des idées il y en a plein et l’on sait pour le vivre les difficultés auxquelles on se heurte à vouloir les concrétiser. Mais là, peut importe si l’on retient l’inventeur ou les réalisateurs : c’est le même.

numerunique présente ses créations

A l’occasion du premier anniversaire du TechShop où numerunique a trouvé le biotope favorable à l’épanouissement de sa nouvelle branche d’activité, numerunique présentera ses créations d’objets uniques dont les plus récentes, telles que son mugcover et son doubledose :

Un couvercle à mug

Un doubleur de dose.

Pour en savoir plus sur ces objets, rendez-vous au marché des créateurs, de 10:00 à 18:00 les 19 et 20 mai prochains au TechShop , 30 rue Henri Régnault à Lille.

Les qrcodes de numerunique

Les objets de numerunique sont uniques.

Cette unicité est garantie par un code d’identification unique dont la validité est vérifiable sur le site de numerunique. Un qrcode propre à chaque objet facilite cette vérification, comme par exemple :

Ce qrcode n’a rien à voir avec les code-barres EAN qui identifient un type d’article produit à grande échelle en un nombre potentiellement infini d’exemplaires. Même les objets semblables de numerunique ont leur propre code d’identification unique !

De plus, le qrcode d’un objet de numerunique est traité de façon unique. Par défaut, il permet de confirmer l’authenticité de l’objet mais il peut tout aussi bien permettre d’accéder à un traitement spécial, défini pour chaque objet. Ainsi, certaines cartes de visite de numerunique ont un qrcode qui amène directement sur la page de contact du site Internet principal de numerunique, d’autres à la page d’accueil de celui présentant les objets de numerunique et le qrcode ci-dessus vous amène à cet article.

Et bien d’autres services offerts par ces qrcodes sont réalisés ou prévus.

Il est déjà possible de se déclarer le propriétaire d’un objet numerunique et même de l’acheter avec un paiement en ligne 🙂

Bientôt, on pourra le déclarer perdu. En flashant le qrcode, celui qui l’aura trouvé se verra proposer de le renvoyer à numerunique qui le restituera à son propriétaire.

Comment bloquer les spams téléphoniques

On reçoit tous des appels téléphoniques inopportuns en tous genres, au point qu’on en arrive à généraliser un accueil téléphonique glacial même à ses proches.

La solution la plus évidente est le recours à la liste noire.  Pour faciliter cela, numerunique partage gratuitement un système de blocage en deux clics  (https://numerunique.fr/services/ABL/). Hélas, même avec 1044 numéros en liste noire, on est encore dérangé.

Une autre solution s’avère plus efficace : elle consiste à configurer un SVI (Serveur Vocal Interactif) minimaliste :

  • Message d’accueil : “Si vous êtes de la famille ou de nos amis, faites le 1 ; sinon faites le 2.”
  • 1 : ça sonne.
  • 2 : ça raccroche.

Enfin tranquille !

En pratique, ce sont des robots qui lancent les appels, automatiquement, à la place des employés des plateforme d’appels. Dès qu’une cible décroche, le robot fait sonner le poste d’un esclave disponible qui peut alors débiter son baratin en suivant les directives du discours commercial imposé. Les robots actuels sont incapables de comprendre l’annonce d’un SVI ni de taper 1. En bonus, cela épargne aux malheureux qui sont exploités sur les plateforme d’appels d’avoir leurs taux de conversion dégradés par un appel qui n’aboutira à rien.

Meltdown et Spectre, faut-il vraiment s’affoler ?

Noms judicieux, logos, timing (juste après les fêtes de fin d’année), site Internet dédié, matraquage médiatique, GIF montrant une démo de keylogger : le traitement marketing des dernières “failles” de sécurité informatiques est vraiment spectaculaire !

Ce qui l’est beaucoup moins c’est ce qui ressort de l’analyse du risque réel de ces menaces, avec les informations actuellement publiées.

Certes, le “risque” est confirmé par Intel ” software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data” mais juste comme potentiel. A la base, le risque serait induit par l’optimisation de traitement d’un processeur qui profite des temps d’accès à la mémoire pour tenter sa chance en exécutant un code probable sans dispositif de protection d’accès à la mémoire pour cette exécution spéculative.

Cependant les deux articles de référence qui décrivent Meltdown et Spectre indiquent clairement que ces failles nécessitent l’exécution d’un programme sur la machine cible.

Et là, il n’y a rien de nouveau, on sait depuis toujours qu’on a presque perdu la partie contre un pirate dès lors qu’il est capable d’exécuter ses programmes sur la machine que l’on défend. La première préoccupation d’un administrateur système est la fiabilité des utilisateurs de ses machines.

C’est donc logique que les hébergeurs tels qu’OVH ou Online mettent autant d’énergie à appliquer des correctifs, tout en précisant qu’à ce jour il n’ont aucune preuve que ces attaques pourraient se réaliser en vrai ” To date, OVH has not received any information demonstrating that the concerned vulnerabilities have been exploited outside of a research laboratory setting.” Les hébergeurs savent que parmi leurs centaines de milliers de clients qui ont accès à leur machines, il y a certainement plus d’une crapule.

Dans le papier “universitaire” qui décrit Spectre, sur lequel pas moins de 10 auteurs se sont agglutinés, l’assemblage des techniques utilisées pour exploiter la faille hardware est impressionnante au point qu’on peut se demander si la somme des conditions favorables à l’exploit ne le rendrait finalement très peu probable. Il y a au moins un aspect décisif facile à comprendre qui n’est pas clair : le succès de la technique dépend-il de la présence de certaines instructions particulières dans un programme cible dont on veut dérober les informations détenues en mémoire ? On y donne un exemple de code hallucinant qui peut être exploité :

if (x < array1_size) y = array2[array1[x] * 256];

C’est bien de vérifier si l’index x est dans les limites du tableau array1 mais alors pourquoi ne pas aussi vérifier que l’index (array1[x]*256) est aussi dans les limites de array2 ? Si ce code est celui écrit par le pirate, il fait ce qu’il veut mais a priori il n’aura accès qu’au contexte de son propre programme comme l’article le précise “The completed attack allows the reading of memory from the victim process.“. Si ce code doit figurer dans celui d’un autre programme exécuté sur la machine alors la probabilité qu’un tel code existe parait plus que très faible.

Il y a de nombreuses autres conditions ou réserves évoquées ou exprimées dans cet article telles que “Kernel mode testing has not been performed, but the combination of address truncation/hashing in the history matching and trainability via jumps to illegal destinations suggest that attacks against kernel mode may be possible.

Tout cela change complètement la réalité de la menace.

Malheureusement cela n’enlève rien aux conséquences qu’elle a déjà engendrées et qui sont irréversibles : un tsunami de mises à jour, une version plus qu’améliorée de l’obsolescence programmée 🙁

Meltdown and Spectre: the juiciest bug of 2018?

2018 starts wonderfully: a new kind of vulnerability has been disclosed, an hardware bug!

Documentation about this is available from sources with considerable authority, from university researcher or google official blog.

However, a closer analysis of the threats raises doubts about their seriousness. The risk to be affected by them seems rather low.

“...Meltdown allows an adversary who can run code on the vulnerable processor…” [https://meltdownattack.com/meltdown.pdf]. Thus for dedicated server, the vulnerability implies a logged attacker. Of course for VM or VPS, you don’t control who runs code on the physical host you share. But servers administrator core preoccupation is to keep attacker from logging on their systems.

As for “Spectre” [https://spectreattack.com/spectre.pdf], the so called proof of vulnerability – among other prerequisites unlikely to happen – relies on the “victim” code to have an instruction such as “if (x < array1_size) y = array2[array1[x] * 256];“! Who would write such a code and what for?

These two quoted papers remind of academic context where such unpractical conditions hidden behind well handled complexity are often observed. The underlying techniques are too complex to be easily understood but the presentation is convincing.

Even google (https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html) admits that “To take advantage of this vulnerability, an attacker first must be able to run malicious code on the targeted system.

Anyway, even if the risk is much lower that it is presented, the inevitable result will be a massive update frenzy: an ideal opportunity to deploy other vulnerabilities, spywares or backdoors and to motive hardware replacement…

First, the software fix will decrease performance: a motivation to invest in faster – and more expensive – systems. Eventually the hardware fix will require new computers. Thus it is not surprising that all CPU vendors happily admit that their products are affected.

Whatever dangerous Meltdown and Spectre may be, they are certainly a huge opportunity of profit.

Well done.

 

L’EURL Barme change de nom commercial…

… et s’appelle désormais numerunique :

En fait une société a trois identifiants :

  1. sa dénomination ou raison sociale,
  2. son nom commercial,
  3. son enseigne commerciale.

Ce nouveau nom commercial reflète davantage l’activité de numerunique. C’est la contraction de numérique et unique et justement, lorsque on fait le bilan de son activité depuis bientôt 10 ans, numerunique fourni des services numériques si personnalisés qu’il sont en fait uniques.

Ce changement – dans la continuité, car c’est toujours la même entité et elle conserve sa raison sociale – est renforcé par un nouveau logo, produit par numerunique.art, plus conforme lui aussi à l’activité de numerunique :

A gauche le 0 symbolise le numérique, à droite, le 1 symbolise l’unique et, au centre, les deux fusionnent dans un objet binaire en 3 dimensions qui symbolise la concrétisation des services numériques uniques de numerunique.

Comparaison de quelques types d’accès à Internet

Quelques tests de différents type d’accès à Internet donnent :

Type d’accès IP Réception max Envoi max Latence min gigue
Wi-Fi distant fixe 0.241 0.657 0.36 0.514 186.1 39 1060
Ethernet via CPL fixe 5.523 5.758 0.708 0.788 42.17 39.8 7.4
Wi-Fi Orange 3G variable 8.194 11.28 0.417 0.542 268.2 91.58 332.3
Wi-Fi proche fixe 11.89 12.28 0.791 0.84 80.91 38.91 171.2
Ethernet direct fixe 11.95 12.12 0.639 0.708 41.05 37.54 8.39
Wi-Fi Free 4G variable 70.87 77.5 7.28 8.988 129.5 54.17 158.2

Les débits de réception et d’envoi sont en Mb/s, la latence et la gigue en ms.

Pour la meilleure réception :

  1. Wi-Fi Free 4G
  2. Ethernet direct
  3. Wi-Fi proche
  4. Wi-Fi Orange 3G
  5. Ethernet via CPL
  6. Wi-Fi distant

Pour l’envoi le plus rapide :

  1. Wi-Fi Free 4G
  2. Wi-Fi proche
  3. Ethernet via CPL
  4. Ethernet direct
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

Pour la meilleure réactivité :

  1. Ethernet direct
  2. Ethernet via CPL
  3. Wi-Fi proche
  4. Wi-Fi Free 4G
  5. Wi-Fi distant
  6. Wi-Fi Orange 3G

Pour la meilleure stabilité :

  1. Ethernet via CPL
  2. Ethernet direct
  3. Wi-Fi Free 4G
  4. Wi-Fi proche
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

Synthèse (tous critères) :

  1. Ethernet direct
  2. Wi-Fi Free 4G
  3. Ethernet via CPL
  4. Wi-Fi proche
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

En bref :

  • La 4G est vraiment rapide à défaut d’être stable.
  • L’Ethernet direct et le wifi proche se valent.
  • Le pire est le Wi-Fi trop distant.

Ces conclusions sont juste indicatives : en pratique, les résultats des tests sont spécifiques à un lieu et un moment donnés.