Il faut également remonter la demande à OpenSSH, non ?

Chaque trois semaines, des centaines de correctifs dans le noyau Linux sont distribués, ils corrigent quoi ?

Il n'y a pas que des failles de sécurité qui sont corrigées. Il y a aussi des bugs qui peuvent vous impacter.

Je vais m'attarder sur un exemple précis de régression qui entraînait des période(s) de 200 millisecondes où le transfert réseau est interrompu, entraînant une baisse de débit moyen pouvant aller jusqu’à 10%, pour les connexions TCP impactées par cette violation de la RFC793. Les RFC sont des documents décrivant les aspects et spécifications techniques d'Internet. Celle-ci date de 1981 et décrit le standard TCP (Transmission Control Protocol) que nous utilisons systématiquement sur Internet, au-dessus d'IPv4 ou d'IPv6. L'alternative possible à TCP est UDP.

Ce bug qui impactait tous les serveurs équipés d'un Linux récent a été découvert et corrigé par... Orange France.
J'ai vraiment été admiratif du travail des équipes d'Orange, qui consiste, quand il y a un bug, à ne pas se limiter à trouver un contournent, mais à chercher l'origine du bug dans le code et proposer un correctif au mainteneur du code en question, pour que le monde entier profite du correctif.

Concrètement pour Ubuntu, le 1^er décembre 2020, le noyau 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 était déployé pour succéder au noyau 5.4.0-54-generic.

Le noyau 5.4.0-55-generic qui intègre plus de 1300 correctifs de bug n'a pas été publié, car la CVE-2020-4788 classée "medium" est arrivée pendant sa phase de validation de non régression. Le 5.4.0-56-generic intègre le 5.4.0-55-generic et rajoute la correction de la CVE-2020-4788.

Dans la liste des 1300 correctifs, il y a tcp: fix receive window update in tcp_add_backlog(), le bug trouvé et corrigé par Orange. On va voir ce qui se cache derrière, les impacts et pourquoi ce type de bug est complexe à trouver.

La régression, découverte par Orange en octobre 2020, était dans le fichier tcp_ipv4.c:tcp_add_backlog(). Non seulement cela pouvait dégrader les performances réseau dans certaines circonstances mais c'était également la source d'un bug dans netfilter, un pare-feu intégré au sein du noyau Linux. Le patch (bugfix) proposé par Orange a été backporté dans la branche stable du noyau Linux et intégré par les différentes distributions plus ou moins rapidement. Pour Ubuntu, il a été poussé à tous le 1^er décembre 2020 avec des centaines d'autres correctifs, dont une faille de sécurité, c'est donc proposé comme une mise à jour de sécurité.

Voici quelques diapositives, publiées avec l'accord d'Orange, qui explique la problématique technique :

Détail technique du problème rencontré :

L’algorithme TCP a dans sa structure deux octets pour indiquer la taille de la fenêtre demandée, c'est-à-dire le nombre d'octets que le récepteur souhaite recevoir sans accusé de réception. Un émetteur n’a strictement pas le droit d’émettre un paquet excédant la RWIN indiquée par le récepteur, comme l’explique la RFC793.

Dans certains cas spécifiques, quand plusieurs paramètres sont réunis, notamment quand le client a une RWIN en diminution forte, jusqu’à devenir nulle nous observons une violation flagrante de la RFC par le serveur qui va envoyer 10ko de payload excédant la RWIN. La diminution de la RWIN est un mécanisme minoritaire, mais fréquent, qui a plus de chances de se déclencher lorsque le débit client est fort, car en situation de débit plus faible, les mécanismes de contrôle de congestion côté serveur prennent le dessus.

Les 10 ko de données envoyés en violation de la RFC793 sont peu, mais suffisant pour placer les piles TCP client et serveur dans un état non souhaité / non prévu :

• Le client va droper ces paquets supplémentaires, faute de mémoire pour les stocker.
• Par la suite le client n’émet que des acquittements TCP avec une RWIN qui continue de diminuer pour devenir nulle.
• Lorsque de la place est de nouveau disponible dans sa mémoire, le client envoie un acquittement au serveur, avec une RWIN non nulle, mais inférieure aux 10ko excédentaires.
• Le serveur reçoit cet acquittement TCP lui indiquant qu’il peut envoyer des paquets... qu’il a déjà envoyé. Le serveur ne fait donc rien.
• Émetteurs et récepteur restent en attente pendant environ 200ms, avant un TLP (Tail Loss Probe) envoyée par le serveur qui fait redémarrer les échanges.

Impacts sur les performances :

Cette problématique peut se produire plusieurs fois dans une même connexion TCP utilisée pour un transfert d’un fichier de 50 Mo.

Les conséquences sont une ou des période(s) de 200 millisecondes où le transfert est interrompu, entraînant une baisse de débit moyen pouvant aller jusqu’à 10%, pour les connexions TCP impactées par cette régression.

Tous les opérateurs sont potentiellement affectés cette violation de la RFC793, en IPv4 comme en IPv6. Cette baisse de débit moyen de 10% concerne uniquement des tests réalisés dans de très bonnes conditions radio.







Précision, ces diapositives ont été crées avant que le bug dans le code Linux soit identifié.

Le correctif, intitulé tcp: fix receive window update in tcp_add_backlog() est présent dans les changelog du noyau diffusé le 1^er décembre 2020 :
- Changelog du noyau Linux 5.4.0-56 du 1^er décembre 2020
- Changelog du noyau Linux 5.8.0-31 du 1^er décembre 2020

On peut remercier Orange pour le travail.

J'ai fait encore d'autres tests ce matin :