Xorg et Wayland sont deux protocoles graphiques utilisés dans les systèmes d’exploitation Unix-like, principalement sur les distributions Linux, pour gérer l’affichage graphique et les interactions avec l’utilisateur.

La plupart des distributions Linux utilisent par défaut Xorg.
Toutefois, lorsque vous installez les pilotes NVIDIA propriétaires ou pour différentes raisons, le gestionnaire de fenêtres peut être Xorg.

Voici comment passer de Xorg à Wayland notamment sur Ubuntu et Debian.

Comment passer sur Wayland dans Linux

Par défaut, Ubuntu utilise Wayland. Toutefois dans le cas où les pilotes propriétaires de NVIDIA sont installés sur Ubuntu, ce dernier repasse sous Xorg (X11).
Cela fonctionne sur Ubuntu 22.04 ou Ubuntu 23.10.
Veuillez noter que Ubuntu 24.04 LTS devrait être par défaut sur Wayland même si les pilotes NVIDIA propriétaires sont installés.

Voici comment activer Wayland avec les pilotes NVIDIA sur Linux :

• Installez la librairies d’implémentation en cours d’une bibliothèque EGL (Embedded-System Graphics Library) pour la plate-forme externe pour Wayland :

sudo apt install libnvidia-egl-wayland1

• Puis éditez le fichier de configuration GRUB :

sudo nano /etc/default/grub

• Repérez la ligne GRUB_CMDLINE_LINUX et éditez pour ajouter la configuration suivante :

GRUB_CMDLINE_LINUX="nvidia-drm.modeset=1"

• Puis mettez à jour la configuration GRUB :

sudo update-grub

• Pour que l’hibernation et mise en veille prolongée fonctionne correctement, il faut activer certaines options. Toutefois le fichier de configuration peut être différents d’une distribution Linux à l’autre
  • Sur Ubuntu, éditez le fichier /etc/modprobe.d/nvidia-graphics-drivers-kms.conf
  • Sur Debian, modifiez le fichier /etc/modprobe.d/nvidia-power-management.conf

options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/tmp/tmp-nvidia
options nvidia-drm modeset=1
options nvidia-drm.fbdev=0 # Pas forcément nécessaire. Consultez la fin de l'article sur les problèmes rencontrés
options nvidia NVreg_UsePageAttributeTable=1
options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1" 

• Redémarrez l’ordinateur pour prendre en compte les modifications

sudo reboot

• Sur l’écran de verrouillage, cliquez sur l’utilisateur
• Puis en bas à droite, cliquez sur l’icône roue crantée puis sélectionnez Wayland (ici il s’agit de l’écran de verrouillage d’Ubuntu)

• Pour vérifier que le bureau de Linux est bien en Wayland :

echo $XDG_SESSION_TYPE

La documentation de Debian fournit aussi une procédure complète pour passer en Wayland : https://wiki.debian.org/NvidiaGraphicsDrivers#Wayland

Comment activer/désactiver Wayland dans GNOME

Le display manager de GNOME (GDM) donne la possibilité de choisir le gestionnaire de fenêtres que vous pouvez utiliser.Vous pouvez très bien activer ou désactiver Wayland dans GNOME.
Voici comment faire :

• Éditez le fichier de configuration de GDM :

sudo nano /etc/gdm3/custom.conf

• Pour forcer l’activation de Wayland dans gnome, positionnez l’option suivante sur True

WaylandEnable=true

• Pour forcer la désactivation de Wayland :

WaylandEnable=false

• Puis relancez GDM :

sudo systemctl restart gdm3

• Vous devriez pouvoir choisir Wayland au démarrage de la session GNOME

Pourquoi passer de X11 à Wayland

Plusieurs raisons peuvent vous pousser à utiliser Wayland à la place de Xorg.
Premièrement, Xorg n’est plus maintenu et vous expose à des problèmes de sécurité. Ce dernier étant un projet de 1980.
Wayland a été lancé afin de proposer un gestionnaire de fenêtre plus moderne, notamment Wayland élimine le modèle client-serveur et permet aux applications d’interagir directement avec le serveur d’affichage.
De plus, Wayland est projet actif, il propose des fonctionnalités qui n’existent pas sur X11.
Dans mon cas, les performances sont vraiment meilleures sur Wayland, l’affichage est beaucoup plus réactif.
C’est aussi le cas dans les jeux.

Quels sont les problèmes connus entre Wayland et les pilotes propriétaires NVIDIA

Le support de Wayland n’est pas encore totale, de plus certaines technologies ne sont pas encore supportés.
Ainsi, des bugs existent.

Les fenêtres en plein écran des jeux et applications rencontrent des problèmes d’affichage.
Certaines parties de la fenêtre sont noires, contiennent des artefacts, clignotements ou encore des bandes horizontales passent de haut en bas révélant un problème de rafraîchissement.
Il existe une discussion à ce sujet : https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317
Vous pouvez tenter d’ajouter MUTTER_DEBUG_FORCE_EGL_STREAM=1 dans /etc/environment et relancez la session GNOME.
Toutefois, il faut savoir que cela risque de poser des problèmes de chargement des jeux mais surtout provoquer des baisses de performances.

De plus, j’ai rencontré des erreurs suivantes qui semblent être à l’origine de freez :

[drm:nv_drm_atomic_commit [nvidia_drm]] ERROR [nvidia-drm] [GPU ID 0x00000 100] Flip event timeout on head 0

D’où la désactivation de fbdev (framebuffer Device – toujours en expérimental) depuis /etc/modprobe.d/nvidia-graphics-drivers-kms.conf :

options nvidia-drm.fbdev=0

En outre, la fréquence adaptative de l’écran (VRR/GSync) n’est pas encore tout à fait disponible.
Les pilotes NVIDIA propriétaires supportent la fonctionnalité depuis la version 545.
Toutefois, ce n’est pas encore le cas des gestionnaire de fenêtres. Par exemple, Gsync est en expérimentale sur la version 46 de GNOME (disponible à partir d’Ubuntu 24.04).
La documentation ArchLinux en parle : https://wiki.archlinux.org/title/Variable_refresh_rate#Limitations

L’article Linux : passer de Xorg (X11) à Wayland est apparu en premier sur malekal.com.

Vous en avez marre de jongler avec une multitude d’outils de gestion de paquets sur vos différents systèmes Linux et Unix ? apt sur Debian, dnf sur Fedora, pacman sur Arch, emerge sur Gentoo, pkg sur FreeBSD… Et je ne parle même pas de Homebrew sur macOS ou Scoop sur Windows ! Bref, un vrai casse-tête pour s’y retrouver et se rappeler de toutes les commandes spécifiques à chaque plateforme.

Heureusement, y’a un p’tit dev malin qui a décidé de nous faciliter la vie. Un certain Sigoden a créé upt, pour Universal Package-management Tool. L’idée c’est d’avoir une interface unique pour gérer ses paquets, quelque soit le système utilisé. Sous le capot, upt se base sur le gestionnaire natif de chaque OS mais vous permet d’utiliser une syntaxe commune pour les opérations de base : rechercher, installer, mettre à jour ou supprimer un paquet.

Bon alors techniquement, c’est écrit en Rust donc faudra passer par l’installation de cargo et de quelques dépendances. Mais rassurez-vous, c’est assez simple et bien documenté sur le dépôt GitHub du projet. Une fois que c’est fait, vous pourrez utiliser la commande upt de la même façon sur tous vos systèmes. Voici quelques exemples :

upt update pour mettre à jour le gestionnaire
upt install package_name pour installer un paquet
upt upgrade package_name pour le mettre à jour
upt remove package_name pour le désinstaller
upt search keyword pour chercher un paquet

Plutôt cool non ?

Fini les prises de tête à se rappeler si c’est apt search ou dnf search, pacman -S ou emerge… Maintenant on fait tout pareil avec upt !

Et ça supporte tous les outils suivants sous Linux, macOS, Windows, BSD :

Bon, j’avoue qu’il y a quelques petites limitations. Déjà upt n’est qu’une surcouche, donc il faudra quand même connaître les noms exacts des paquets pour chaque distrib. Pas de nom universel type « python3-dev » qui fonctionnerait sur Ubuntu comme sur Fedora.

Ensuite, si un même paquet est dispo dans plusieurs formats (deb, snap, flatpak…), upt va suivre un ordre de priorité pour choisir lequel installer. Mais vous pouvez outrepasser ça en définissant la variable d’environnement UPT_TOOL avec le nom du gestionnaire souhaité.

Par exemple, pour forcer upt à utiliser les paquets snap pour VLC plutôt que apt ou autre :

export UPT_TOOL='snap'
upt install vlc

Dernier point, certaines commandes un peu plus avancées ne seront pas gérées directement par upt. Il faudra alors repasser par le gestionnaire natif. Mais pour une utilisation basique au quotidien, ce petit outil vous fera gagner pas mal de temps et de neurones.

Après, je dis pas que c’est la solution révolutionnaire qui va unifier une bonne fois pour toutes le monde des paquets sur Linux et Unix. Y’a encore du taf pour ça. Mais en attendant, upt est bien pratique pour ceux qui doivent régulièrement passer d’un système à l’autre.

Et puis soyons honnêtes, nous les linuxiens on est un peu maso sur les bords. On aime bien quand c’est compliqué et qu’il faut batailler pour faire un truc. Alors un outil qui simplifie les choses, ça va en rebuter plus d’un ! Mais je suis sûr que ça peut rendre service à pas mal de monde malgré tout.

En attendant, amusez-vous bien et n’oubliez pas : dans le doute, RTFM ! 😄

Source

Parmi les commandes basiques Linux, on trouve la commande more. Elle est principalement utilisée pour afficher le contenu d’un fichier page par page, ce qui permet de lire facilement des fichiers volumineux sans être submergé par un mur de texte.
Elle dispose aussi de fonction de recherche.

Dans ce tutoriel, je vous montre comment utiliser la commande more sur Linux avec des exemples.

Quelle est la syntaxe de la commande more

Voici la syntaxe :

more [-options] [-num] [+/pattern] [+numligne] <nom fichier>

Et la liste des options

Option	Description
-c ou –no-color	Désactive le surlignage en couleur de la sortie.
-n ou –line-numbers	Afficher les numéros de ligne au début de chaque ligne.
-d	L’invite est “[Appuyez sur l’espace pour continuer, sur ‘q’ pour quitter.]”, et affiche “[Appuyez sur ‘h’ pour les instructions.]” au lieu de sonner la cloche lorsque l’on tente de faire défiler le fichier au-delà de la fin.
-l	Ignore le saut de page (^L).
-f	Compte les lignes logiques, plutôt que les lignes d’écran (c’est-à-dire que les lignes longues ne sont pas pliées).
-p	Fait défiler un écran complet.
-c	Efface l’écran avant d’afficher la page.
-s	Réduit le nombre de lignes vierges en une seule.
-u	Mode texte plein en supprimant la mise en forme gras et souligné.

Comment utiliser la commande more sur Linux

Par défaut, plus de commandes sous Linux affichent le fichier une page à la fois.

Vous pouvez naviguer dans le fichier à l’aide de différentes commandes :

Commande	Action
ESPACE ou f	Afficher les x lignes de texte suivantes. La valeur par défaut est la taille actuelle de l’écran.
Entrée	Afficher les x lignes de texte suivantes. La valeur par défaut est 1. L’argument devient la nouvelle valeur par défaut.
d ou ^D	Défiler de x lignes. La valeur par défaut est la taille de défilement actuelle, initialement 11.
s	Sauter x lignes de texte. La valeur par défaut est 1.
f	Sauter x lignes de texte. La valeur par défaut est 1.
b ou ^B	Revenir à x lignes de texte vers l’arrière. La valeur par défaut est 1. Ne fonctionne qu’avec les fichiers, pas avec les pipes.
‘	Aller à l’endroit où la dernière recherche a commencé.
=	Affiche le numéro de la ligne en cours.
q ou Q	Quitter

Recherche dans un fichier

La commande more vous permet également de rechercher une chaîne de caractères spécifique dans un fichier. Cette fonction est particulièrement utile lorsque vous avez affaire à des fichiers volumineux et que vous recherchez des informations spécifiques. Pour ce faire, vous pouvez utiliser le ‘/’ suivi de la chaîne de caractères que vous recherchez.

Voici un exemple :

Dans cet exemple, la commande “more” affiche le contenu de monfichier.txt à partir de la première ligne contenant la “chaîne de recherche”.

more +/"chaîne de recherche" monfichier.txt

Vous pouvez également utiliser des expressions régulières avec l’option /pattern pour rechercher des motifs plus complexes. Par exemple, pour rechercher toutes les lignes commençant par le mot “error”, vous pouvez utiliser la commande suivante :

more /^error/ /var/log/syslog 

Il ne s’agit là que de quelques exemples d’utilisations avancées de la commande ‘more’. Comme vous pouvez le constater, ‘more’ est un outil puissant pour visualiser et naviguer dans les fichiers sous Linux. Cependant, comme tout outil, il a ses avantages et ses inconvénients, et son utilisation dépend des exigences spécifiques de la tâche à accomplir.

Visualiser plusieurs fichiers

L’une des fonctions les plus puissantes de la commande more est la possibilité d’afficher plusieurs fichiers de manière séquentielle. Par exemple, si vous avez trois fichiers texte – fichier.txt, fichier2.txt et fichier3.txt – vous pouvez les afficher en séquence avec la commande suivante :

more fichier1.txt fichier2.txt fichier3.txt

Dans cet exemple, la commande “more” affiche d’abord le contenu du fichier1.txt. Lorsque vous aurez fini de visualiser le fichier1.txt, elle affichera le contenu du fichier2.txt, et ainsi de suite.

• Pour passer au fichier suivant, appuyez sur :n. L’observateur se déplace alors au début du fichier suivant.
• Pour reculer d’un fichier, appuyez sur :p. Cela permet de revenir au début du fichier précédent.

Vous pouvez bien entendu utiliser le caractère joker, par exemple pour visualiser tous les fichiers dictionnaires :

more /usr/share/dict/*

Afficher que X lignes par pages

Une autre option est utile est l’option -n suivi qui vous permet de définir le nombre de lignes à afficher par page.
Par exemple pour n’afficher que 5 lignes par page d’un fichier :

more -n 5 fichier.txt

Ouvrir un fichier à la première occurrence d’une recherche

Pour ouvrir un fichier à un numéro de ligne, passez l’option + accompagnée d’un numéro de ligne.
Par exemple pour ouvrir

more +130000 /usr/share/dict/french

L’article Utiliser la commande more sur Linux avec des exemples est apparu en premier sur malekal.com.

Dans un tutoriel précédent, je présentais différentes commandes Linux (jobs, fg, …) afin de pouvoir exécuter des processus en arrière-plan.
Mais à la fermeture du terminal, un signal SIGHUP (Signal Hang UP) est envoyé pour terminer tous les processus du shell.
C’est là qu’intervient la commande disown qui permet de marquer un travail et donc un processus afin de ne pas lui envoyer ce SIGHUP pour qu’il puisse continuer à s’exécuter une fois le shell fermé.
De plus, elle permet aussi de retirer chaque des travaux spécifiques de la table des tâches actives.

Dans ce tutoriel, je vous montre comment utiliser la commande disown de Linux.

Quelle est la syntaxe de la commande disown

Voici la syntaxe :

disown <options> <job-id>

Où :

• <options> : Il existe plusieurs options, mais la plus courante est “-h”, qui indique au shell de ne pas envoyer de HUP (HangUP) lorsque le shell parent se termine.
• <job-id> : L’identifiant du travail (job) que vous souhaitez dissocier du shell. Vous pouvez trouver l’identifiant du travail en utilisant la commande “jobs” dans le shell.

Comment utiliser la commande disown

Comment continuer à exécuter un travail après avoir quitté une invite shell en arrière-plan

Quelques rappels rapides concernant l’exécution de commandes sur Linux.
Pour lancer une commande qui s’exécute en arrière plan, ajoutez le caractère & à la fin de la commande.
Par exemple pour lancer le téléchargement d’un fichier avec wget en arrière-plan et l’ouverture d’un fichier avec vim :

wget -O /dev/null -q http://bouygues.testdebit.info/10G.iso&
[1] 226923
vim /tmp/univers.txt &
[2] 226940

Pour lister les travaux en cours, utilisez la commande jobs :

jobs -l
[1]- 226923 En cours d'exécution   wget -O /dev/null -q http://bouygues.testdebit.info/10G.iso &
[2]+ 226940 Arrêté (via la sortie sur tty)        vim /tmp/univers.txt

• La commande wget est indiquée par “-“, ce qui signifie qu’elle deviendra la tâche active si la commande vim est interrompue
• La commande vim est désignée par “+”, ce qui signifie qu’il s’agit d’une tâche active

Seulement, si vous fermez le terminal ou la session SSH, l’exécution de la commande s’arrête aussi car le système envoie un signal pour terminer toutes les commandes rattachées au shell.
C’est là que la commande disown entre en jeu car elle permet de dissocier un processus du shell. Ainsi, si vous fermez le shell, son exécution continue.

Lorsque vous quittez le terminal de votre système, tous les travaux en cours sont automatiquement interrompus. Pour éviter cela, utilisez la commande disown avec l’option -h :

disown -h <%jobID>

Dans notre exemple, nous voulons que la commande wget continue à fonctionner en arrière-plan. Pour éviter qu’elle ne se termine à la sortie, utilisez la commande suivante :

disown -h %1

Tous les travaux pour lesquels vous avez utilisé la commande disown -h continueront de fonctionner.

Autre exemple, imaginons que vous souhaitez exécuter une mise à jour du système avec apt-get en root en arrière-plan et qui ne s’arrête pas si la session se termine.
Voici les commandes à utiliser :

sudo -i # Pour devenir root
apt-get upgrade &> /root/system.update.log & # Mise à jour du système avec redirection de la sortie dans un fichier
disown -h # Marquer apt-get pour que SIGHUP ne soit pas envoyé à la sortie
exit # On quitte le shell root

Supprimer tous les travaux en cours avec la commande disown

Sans aucune option, chaque jobID est supprimé de la table des jobs actifs, c’est-à-dire que l’interpréteur de commandes bash utilise sa notion du job en cours qui est affiché par le symbole + dans la commande jobs -l :

disown

Pour supprimer tous les travaux en cours d’exécution, utilisez l’option -r :

disown -r

Pour supprimer tous les travaux, utilisez l’option -a :

disown -a

Suppression de travaux spécifiques

Pour supprimer un travail spécifique du tableau des travaux, utilisez la commande disown avec l’identifiant de travail approprié. L’ID du travail est indiqué entre parenthèses dans le tableau des travaux :

Dans notre exemple, si nous voulons supprimer la commande vim, nous devons utiliser la commande disown sur le job 2 :

disown %2

L’article La commande disown Linux : utilisations et exemples est apparu en premier sur malekal.com.

Le sous-système Windows pour Linux (WSL) de Microsoft change la donne en offrant une expérience Linux complète au sein de Windows.
Lorsqu’on utilise une distribution WSL, on peut avoir besoin de transférer des fichiers entre Windows et Linux.
Ne vous inquiétez pas, accéder aux fichiers Windows depuis WSL et inversement est relativement simple.

Dans ce tutoriel, je vous donne toutes les étapes pas à pas pour y parvenir.

Comment transférer facilement des fichiers de Windows vers le WSL à l’aide de l’Explorateur de fichiers

Voici comment accéder aux dossiers de la distributions WSL dans Windows afin de pouvoir transférer des fichiers.

• Ouvrez l’explorateur de fichiers et, dans la barre d’adresse, tapez \\wsl$ puis appuyez sur Entrée.
• L’Explorateur de fichiers affiche les dossiers racine du WSL avec la liste des distributions Linux

• Ouvrez la distribution Linux avec laquelle vous travaillez
• Naviguez dans l’arborescence des dossiers jusqu’à ce que vous atteigniez votre dossier personnel /home/<nom-utilisateur>

• Cliquez avec le bouton droit de la souris sur le dossier contenant votre nom d’utilisateur et cliquez sur Épingler à l’accès rapide. Vous disposez maintenant d’un moyen pratique de naviguer vers votre dossier d’accueil WSL sur votre panneau de gauche

• A partir de là, vous pouvez copier des fichiers vers ce dossier ou encore créer de nouveaux fichiers

Comment accéder facilement aux fichiers Windows à partir du WSL

Par /mnt

Si vous souhaitez accéder facilement aux répertoires des utilisateurs Windows dans WSL, vous pouvez tirer parti des liens symboliques de Linux.
Depuis WSL, vous pouvez accéder à l’arborescence de Windows via /mnt/c.

Pour simplifier l’accès à vos fichiers personnels, vous pouvez créer un lien symbolique dans votre répertoire home.
Voici comment faire :

• Assurez-vous d’être dans votre répertoire personnel.

cd

• Créez un répertoire. Appelons-le “winhome”.

mkdir winhome

• Créez un lien symbolique vers votre dossier utilisateur Windows qui mène à ce nouveau répertoire.

ln -s /mnt/c/Users/<nom-utilisateur>/ ~/winhome

• N’oubliez pas de remplacer <nom-utilisateur> par votre nom d’utilisateur Windows. L’affichage du répertoire winhome devrait maintenant montrer un lien symbolique réussi.
• Après cela, vous pouvez accéder au dossier ~/winhome/<nom-utilisateur> qui vous donne accès à vos fichiers personnels

Si nous lançons un gestionnaire de fichiers dans WSL, nous pouvons voir l’arborescence de notre répertoire Windows depuis l’environnement Linux.

L’article WSL : accéder, transférer facilement des fichiers est apparu en premier sur malekal.com.

Dans quelques jours, Microsoft va participer à l'Open Source Summit 2024, mais pourquoi ? Bien que cela puisse surprendre, sachez qu'au final, c'est plutôt évident et cohérent.

L'Open Source Summit North America est un événement organisé par la Fondation Linux et l'édition 2024 se déroulera du 16 au 18 avril prochain, à Seattle, aux États-Unis. Microsoft va participer à cet événement mondial, tout en étant un sponsor "Platinum", au même titre que Docker et Red Hat. D'ailleurs, au passage, AWS et Google sont des sponsors "Diamond" de cet événement.

Bien que Microsoft soit toujours associé à une étiquette d'"éditeur de solutions propriétaires", notamment parce que son système d'exploitation Windows est un OS propriétaire, la position de l'entreprise américaine a évoluée depuis environ 10 ans. Depuis 2014 et l'arrivée en Satya Nadella en tant que Directeur général, pour être plus précis. Si Microsoft a commencé à adopter l'open source dans ses activités principales et à participer à différents projets, c'est grâce à lui.

Microsoft est impliqué dans de nombreux projets Open Source

À l'occasion de sa participation à l'Open Source Summit, Microsoft discutera de ses contributions à la communauté open source. Aujourd'hui, Microsoft se félicite de participer au développement de Linux, à des langages de programmation tels que PHP, Python et Node.js, mais aussi à PostgreSQL ou encore à ses propres solutions open source comme .NET Core, Visual Studio Code et TypeScript.

"En outre, l'open source est au cœur de notre stratégie produit et constitue un élément fondamental de notre culture. Aujourd'hui, plus de 60 000 employés de Microsoft utilisent GitHub et nous gérons plus de 14 000 dépôts publics couvrant tout, des meilleures pratiques et de l'ensemble de nos systèmes de documentation aux projets innovants tels que PowerTools et PowerShell.", peut-on lire sur le site de Microsoft.

La firme de Redmond partagera également ses meilleures pratiques pour l'utilisation des technologies open source et les tendances émergentes dans ce domaine. D'ailleurs, en interne, Microsoft a eu équipe en charge de veiller sur la bonne utilisation des logiciels libres : "Le Microsoft Open Source Programs Office (OSPO) veille à ce que nous utilisions correctement les logiciels libres, à ce que nous fournissions des solutions sécurisées à nos clients et à ce que nous participions de manière authentique aux communautés de logiciels libres."

Pour Microsoft, l'intérêt est aussi d'assurer une compatibilité et une prise en charge avec ses solutions telles que Microsoft Intune ou encore le Cloud Azure au sein duquel les organisations peuvent exécuter des machines virtuelles sous Linux. "Microsoft prend en charge les principales distributions Linux et collabore étroitement avec Red Hat, SUSE, Canonical et l'ensemble de la communauté Linux.", précise Microsoft.

The post Microsoft va participer à l’Open Source Summit 2024 : pourquoi ? first appeared on IT-Connect.

Si vous êtes développeur, vous connaissez certainement Notepad++. Il s’agit d’un éditeur de texte et de code source surpuissant sous Windows. Cependant, pour les utilisateurs de macOS et Linux, la quête d’un outil similaire (à la fois puissant et polyvalent) peut s’avérer être un défi. Aujourd’hui, je vous propose de découvrir Notepad Next. Il s’agit d’un outil simple, efficace, multi-plateforme et gratuit ! Notepad Next Notepad Next est une logiciel open source et gratuite qui fonctionne sous Windows, Linux et macOS. Les développeurs derrière cet outil ne cachent pas leur grande inspiration tirée du célèbre Notepad++. Ils ont créé un […]
Lire la suite : Notepad Next : Notepad++ pour macOS et Linux

Dans le monde de la cybersécurité, la découverte de failles 0day critiques est un enjeu important, car elles peuvent être exploitées par des acteurs malveillants pour compromettre des systèmes qui n’ont pas encore eu le temps d’être mis à jour.

Récemment, un chercheur en sécurité a fait une découverte plutôt alarmante : 2 failles 0day sont présentes dans les noyaux Linux 6.4 à 6.5. Cependant, cette histoire a pris une tournure inattendue… En effet, il y a quelques jours, le chercheur en sécurité, connu sous le pseudonyme YuriiCrimson, a publié sur GitHub les détails de 2 exploits pour des failles 0day qu’il avait découverts dans le pilote n_gsm des noyaux Linux.

Sauf que l’une de ces 2 failles avait en réalité déjà été divulguée par un autre chercheur, Jmpeax. D’après YuriiCrimson, celui-ci lui aurait racheté pour la publier comme si c’était sa propre découverte. Il explique sur sa page Github qu’ignorant cette divulgation, il a involontairement « re-divulgué » sa propre découverte.

Face à cette situation assez malaisante, YuriiCrimson a alors décidé de « riposter » en publiant immédiatement un second exploit, encore inconnu, affectant une plage plus large de noyaux Linux, des versions 5.15 à 6.5. Cette nouvelle divulgation un peu précipitée ayant pour but de couper l’herbe sous le pied de Jmpeax et de prouver à tout le monde que c’était bien lui, le papa de la première vuln.

Ah l’égo !

Si tout cela se confirme, ça met en lumière plusieurs problématiques. Tout d’abord, racheter le travail d’un autre chercheur pour se l’attribuer c’est très moche. Et vendre son travail pour ensuite le rendre public, c’est très moche aussi.

De plus, la divulgation non coordonnée de failles 0day peut avoir des conséquences désastreuses. En rendant publics les détails d’exploitation avant que les éditeurs n’aient pu corriger les vulnérabilités, on expose les systèmes à des attaques immédiates. Une divulgation responsable, en collaboration avec les éditeurs concernés, permet donc de laisser le temps nécessaire pour développer et déployer des correctifs, protégeant ainsi les utilisateurs.

Voilà, c’était l’histoire cybersec moche du jour, dont nous sommes maintenant tous victimes, car il y a 2 jolis 0day non encore patchés qui se baladent.

Bref, gaffe à vos systèmes…

Des chercheurs en sécurité ont découvert une vulnérabilité qu'ils considèrent comme le "premier exploit natif Spectre v2" qui affecte les systèmes Linux fonctionnant avec de nombreux processeurs Intel récents ! En exploitant cette vulnérabilité, un attaquant pourrait lire des données sensibles dans la mémoire. Voici ce qu'il faut savoir !

La vulnérabilité Spectre et l'exécution spéculative

Avant tout, commençons par quelques mots sur la vulnérabilité Spectre en elle-même, ainsi que sur l'exécution spéculative.

Découverte au sein des processeurs Intel et AMD il y a plusieurs années, Spectre et sa copine Meltdown sont parmi les vulnérabilités les plus populaires. Ces termes font aussi référence à des techniques d'attaques visant à exploiter les failles de sécurité en question. Spectre affecte de nombreux processeurs dotés de l'exécution spéculative et corriger cette faille de sécurité matérielle n'est pas simple, car cela affecte, de façon importante, les performances du CPU.

L'exécution spéculative vise à améliorer les performances de la machine grâce au processeur qui va chercher à deviner la prochaine instruction à exécuter. La puissance des processeurs modernes permet de prédire plusieurs chemins qu'un programme peut emprunter et les exécuter simultanément. Cela ne fonctionne pas toujours, mais quand c'est le cas, cela booste les performances. Malgré tout, cela représente un risque, car le cache du CPU peut contenir des traces avec des données sensibles (mots de passe, informations personnelles, code logiciel, etc.), et celles-ci sont potentiellement accessibles par un attaquant lorsqu'une vulnérabilité est découverte.

Il y a deux méthodes d'attaques nommées Branch Target Injection (BTI) et Branch History Injection (BHI).

L'exploitation de Spectre V2 sur Linux

Récemment, une équipe de chercheurs du groupe VUSec de VU Amsterdam a fait la découverte de Spectre V2, une nouvelle variante de l'attaque Spectre originale, associée à la référence CVE-2024-2201. Vous pouvez retrouver leur rapport sur cette page.

Le CERT/CC a mis en ligne un bulletin de sécurité à ce sujet, dans lequel nous pouvons lire ceci : "Un attaquant non authentifié peut exploiter cette vulnérabilité pour faire fuir la mémoire privilégiée du CPU en sautant spéculativement vers un gadget choisi.", c'est-à-dire un chemin de code.

Dans le cas présent, le nouvel exploit, appelé Native Branch History Injection (en référence à l'attaque BHI), peut être utilisé pour faire fuir la mémoire arbitraire du noyau Linux à une vitesse de 3,5 kB/sec en contournant les mesures d'atténuation existantes de Spectre v2/BHI.

Pour se protéger, le CERT/CC recommande d'appliquer les dernières mises à jour publiées par les éditeurs et précise ceci : "Les recherches actuelles montrent que les techniques d'atténuation existantes, à savoir la désactivation de l'eBPF privilégié et l'activation de l'IBT, sont insuffisantes pour empêcher l'exploitation de BHI contre le noyau/l'hyperviseur."

De son côté, Intel a mis à jour ses recommandations d'atténuation pour Spectre v2 et propose désormais de désactiver la fonctionnalité "Extended Berkeley Packet Filter" non privilégiée (eBPF), d'activer les fonctionnalités "Enhanced Indirect Branch Restricted Speculation" (eIBRS) et "Supervisor Mode Execution Protection" (SMEP).

Voici une vidéo de démonstration d'exploitation de cette vulnérabilité :

Qui est affecté par la vulnérabilité Spectre V2 ?

Le noyau Linux étant affecté, cette vulnérabilité va forcément impacter de nombreuses distributions. L'équipe de développement du noyau Linux mène actuellement des travaux pour trouver une solution. Mais, en fait, l'impact dépend aussi du matériel, car la vulnérabilité Spectre V2 affecte les processeurs Intel, et non les processeurs AMD.

D'un point de vue du système d'exploitation, si nous visitons le site de Debian, nous pouvons voir que les différentes versions sont vulnérables (Sid, Bookworm, Bullseye, Buster, etc.). SUSE Linux est également impactée, comme le mentionne cette page. Du côté de Red Hat Linux Enterprise, on affirme que l'eBPF non privilégié est désactivé par défaut, de sorte que le problème n'est pas exploitable dans les configurations standard.

Une liste publiée sur la page du CERT/CC permet d'accéder facilement aux liens des différents éditeurs et d'effectuer le suivi dans les prochains jours.

Finalement, cette nouvelle découverte souligne la difficulté de trouver un équilibre entre l'optimisation des performances et la sécurité, puisque ceci pourrait contraindre les utilisateurs à se passer de certaines fonctionnalités relatives au CPU.

Source

The post L’attaque Spectre v2 affecte les systèmes Linux avec un processeur Intel ! first appeared on IT-Connect.

Researchers have demonstrated the "first native Spectre v2 exploit" for a new speculative execution side-channel flaw that impacts Linux systems running on many modern Intel processors. [...]

Vous êtes-vous déjà demandé ce que vos applications faisaient dans votre dos ? Quelles données elles envoyaient sur Internet à votre insu ? Je suis sûr que oui !

C’est pourquoi, si vous êtes soucieux de votre confidentialité et de la sécurité de vos informations, il est temps de faire connaissance avec OpenSnitch, le pare-feu interactif qui va vous permettre de mieux sécuriser et gérer les connexions sur votre ordinateur Linux.

Inspiré du célèbre Little Snitch sur macOS, OpenSnitch agit comme un garde-fou en vous alertant chaque fois qu’un programme tente d’établir une connexion sortante. Comme ça, plus besoin de laisser les applications communiquer sans votre consentement, vous avez le contrôle !

OpenSnitch utilise évidemment iptables couplé à NFQUEUE et ftrace présent par défaut dans le noyau pour détecter et alerter l’utilisateur d’un poste client Linux que quelque chose ne tourne pas rond. Top pour détecter les trucs louches comme l’exploitation d’une faille ou une fuite de données.

L’interface d’OpenSnitch est simple à prendre en main. Lorsqu’une application essaie d’accéder à Internet, une pop-up apparaît, vous donnant toutes les informations nécessaires pour prendre votre décision : le nom de l’application, l’adresse IP et le port de destination, et même le chemin de l’exécutable. Vous pouvez alors choisir d’autoriser ou de bloquer la connexion, de manière ponctuelle ou permanente.

OpenSnitch ne se contente pas de filtrer les connexions puisqu’il vous permet également de garder un œil sur l’activité réseau de votre système. Via son interface graphique, vous pourrez consulter l’historique des connexions, voir quelles applications communiquent le plus, et même exporter les données pour une analyse plus poussée.

Pour l’installer sous Ubuntu, récupérez les .deb ici et lancez la commande :

sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb

Et pour le lancer :

opensnitch-ui

OpenSnitch est disponible dans les dépôts de la plupart des distributions Linux, et son installation se fait en quelques commandes. Vous pouvez même l’essayer dans une machine virtuelle pour vous faire une idée avant de l’adopter sur votre système principal.

Plus d’infos ici !

Article paru initialement le 13 juin 2017 – Mis à jour le 8 avril 2024

Lorsque l’on quitte le shell d’un système Linux, tous les processus en cours sont généralement interrompus ou bloqués.
C’est là que la commande nohup peut vous être utile.
Tous les processus exécutés à l’aide de la commande nohup ignoreront le signal SIGHUP (Signal Hang UP), même après avoir quitté l’interpréteur de commandes.
Cela permet donc d’exécuter des commandes en arrière-plan sans qu’il soit arrêter si vous fermez le terminal ou la session SSH.

Dans ce tutoriel, je vous explique comment utiliser la commande Nohup de Linux.

Comment utiliser la commande Nohup sur Linux

Démarrage d’un processus en arrière-plan à l’aide de Nohup

Dans ce premier exemple, vous souhaitez lancer en arrière-plan le téléchargement d’un fichier iso avec la commande wget.

nohup wget http://exemple.com/monfichier.iso &

Cette commande utilise nohup pour lancer un processus wget afin de télécharger un fichier volumineux.
En ajoutant & à la fin, la commande s’exécute en arrière-plan, ce qui permet d’utiliser le terminal pour d’autres tâches. Le processus se poursuit même si l’utilisateur se déconnecte, ce qui garantit que le téléchargement s’effectue sans surveillance.
La commande vous indique le numéro du travail entre crochet sui par le PID du processus :

[1] 33186

Vous pouvez lister les travaux en arrière-plan à l’aide de la commande jobs :

jobs -l

Si le script ou la commande ne produit aucune sortie standard, cette sortie est écrite dans nohup.out et non dans le terminal. Pour vérifier la sortie, nous pouvons utiliser tail pour suivre les mises à jour effectuées dans le fichier.

tail -f nohup.out

Arrêter le processus en arrière-plan

Si vous souhaitez arrêter ou tuer le processus en cours, utilisez la commande kill suivie de l’identifiant du processus, comme suit

kill 33186

Comment rediriger la sortie de la commande nohup

Imagions le cas où vous souhaitez exécuter un script en arrière-plan, tout en récupérant la sortie dans un fichier.
Cela est possible grâce aux redirections de sortie Linux.

nohup ./script.sh > output.log 2>&1 &

Dans cette exemple, la commande nohup exécute un script personnalisé (script.sh).
La redirection de la sortie est utilisée ici (> output.log 2>&1) pour capturer à la fois la sortie standard et l’erreur standard dans un fichier nommé output.log, garantissant ainsi que toute sortie du script est sauvegardée pour un examen ultérieur. Le & à la fin exécute le processus en arrière-plan.

L’article Commande Nohup sur Linux : utilisations et exemples est apparu en premier sur malekal.com.

Envie d’un terminal nouvelle génération qui allie performance et flexibilité ? Ne cherchez plus, Alacritty est fait pour votre bonheur !

Disponible sur toutes les plateformes qui comptent (Linux, macOS, Windows, BSD ^^), ce terminal au look sobre et épuré cache sous son capot une configuration ultra complète. Pas besoin de réinventer la roue, Alacritty s’intègre avec vos applications préférées pour vous offrir une expérience sur-mesure sans compromis sur la vitesse. Bon OK, c’est encore un peu jeune, il est un peu long à configurer et il reste quelques fonctionnalités à ajouter et bugs à corriger, mais ça n’empêche pas de nombreux baroudeurs du shell de l’utiliser quotidiennement. YOLO comme on dit.

Mais Alacritty, c’est pas qu’un simple émulateur de terminal de base. Il embarque des features bien pratiques pour améliorer la vie des accros de la ligne de commande :

• Vous aimez vim ? Ça tombe bien, avec le mode Vi vous pouvez retrouver vos réflexes pour vous déplacer et sélectionner du texte.
• Vous avez la flemme de scroller manuellement pour retrouver une commande ou une erreur ? Utilisez la recherche intégrée pour localiser ce que vous voulez en un clin d’œil.
• Vous en avez marre de jongler entre votre souris et votre clavier ? Avec les hints façon regex, plus besoin de quitter le clavier, interagissez avec n’importe quel texte à l’écran.
• Votre PC rame quand vous ouvrez 10 terminaux en même temps ? Pas de problème, avec le mode multi-fenêtres , un seul process Alacritty est partagé intelligemment.

Et je vous ai parlé que de quelques fonctionnalités, y’en a bien d’autres à découvrir dans la doc.

Après la théorie, passons à la pratique. Pour l’installer, c’est ultra simple. Si vous êtes sur macOS ou Windows, direction la page des releases GitHub pour chopper le binaire. Sous Linux ou BSD, il est sûrement déjà dans le gestionnaire de paquets de votre distrib. Sinon, les instructions détaillées vous expliqueront comment compiler depuis les sources.

Une fois installé, pas besoin de vous embêter à configurer, les options par défaut sont déjà pas mal. Mais si vous voulez quand même mettre votre patte, le fichier de config en TOML se trouve, en fonction de votre OS, dans $XDG_CONFIG_HOME/alacritty, $HOME/.config/alacritty ou %APPDATA%\alacritty.

Par exemple, pour l’installer sous macOS, vous pouvez faire également :

brew install --cask alacritty

Puis créer un fichier de config comme ceci :

mkdir -p ~/.config/alacritty && touch ~/.config/alacritty/alacritty.toml

Voici un exemple de config à mettre dedans pour obtenir un truc comme ça :

# Configuration du shell et des variables d'environnement
shell = { program = "/bin/zsh", args = ["-l"] }

[env]
TERM = "xterm-256color"

# Activation du rechargement dynamique de la configuration
#live_config_reload = true

# Configuration de la fenêtre pour un look minimaliste et semi-transparent
[window]
decorations = "buttonless"
dynamic_padding = false
opacity = 0.9
padding = { x = 25, y = 20 }

# Configuration de la police personnalisée avec styles spécifiques pour différents états du texte
[font]
size = 20.0
[font.normal]
family = "JetBrains Mono"
style = "Medium"
[font.bold]
family = "JetBrains Mono"
style = "Heavy"
[font.italic]
family = "JetBrains Mono"
style = "Medium Italic"
[font.bold_italic]
family = "JetBrains Mono"
style = "Heavy Italic"

# Configuration des couleurs
[colors]
[colors.primary]
background = '#282a36' # Arrière-plan foncé
foreground = '#f8f8f2' # Texte clair
[colors.cursor]
text = 'CellBackground'
cursor = '#ff79c6' # Couleur du curseur
[colors.selection]
text = 'CellBackground'
background = '#44475a'

# Configuration du curseur
[cursor]
style = { shape = "Block", blinking = "On" }
thickness = 0.25

# Ajout de raccourcis clavier pour améliorer l'efficacité
[keyboard]
bindings = [
  { key = 'N', mods = 'Control|Shift', action = 'CreateNewWindow' },
  { key = 'C', mods = 'Control|Shift', action = 'Copy' },
  { key = 'V', mods = 'Control|Shift', action = 'Paste' },
  { key = '+', mods = 'Control', action = 'IncreaseFontSize' },
  { key = '-', mods = 'Control', action = 'DecreaseFontSize' },
  { key = '0', mods = 'Control', action = 'ResetFontSize' }
]

Mais du coup, c’est vraiment le terminal le plus rapide ?

Difficile à dire… Mesurer les perfs d’un terminal, c’est compliqué. Sur les benchmarks, en tout cas, Alacritty s’en sort bien, surtout grâce à l’accélération GPU. Après, sur des critères plus subjectifs comme la latence ou la fluidité de l’affichage, difficile de départager les challengers. Le mieux est de l’essayer et de voir s’il convient à VOS usages.

Par contre, ne vous attendez pas à retrouver toutes les fonctionnalités de terminaux plus anciens. Pas de tabs, pas de splits, Alacritty se concentre sur son cœur de métier. Pour ces features, votre gestionnaire de fenêtres ou un multiplexeur comme tmux feront très bien l’affaire. Et si vous voulez faire un peu de customisation, il faudra vous plonger dans la doc.

Après, si jamais il vous manque un truc indispensable, le projet est ouvert aux contributions. Alacritty est d’ailleurs distribué sous licence Apache 2.0. Donc si vous vous sentez de rajouter ce p’tit truc manquant, la communauté vous accueillera à bras ouverts. Comme quoi, y’a pas que Microsoft qui sait faire dans l’open source ! mdr.

En attendant de voir vos pull requests pleuvoir sur ce projet, je ne peux que vous conseiller de tester Alacritty. Vous verrez, c’est le genre d’outil auquel on s’habitue vite et qui change la vie. Bon OK, ça reste un terminal, faut pas exagérer non plus. N’empêche que depuis que j’ai goûté à la fluidité de son rendu, j’avoue que j’aurais du mal à revenir en arrière !

Merci à Lorenper

Lorsque vous vous déconnectez d’une session Linux, le système envoie un signal HUP (hangup) à tous les processus actifs associés au terminal. Ce signal indique aux processus de se terminer.
Mais lorsque l’on administre un système Linux, il peut parfois être nécessaire d’exécuter des commandes en arrière-plan.
Par exemple, car on a besoin de libérer le terminal pour exécuter une seconde commande.
Dans d’autres cas, lorsque l’on prend la main à distance par SSH, il peut être nécessaire que l’exécuter d’un script continue après la fermeture de la session.

Dans ce tutoriel, je vous donne plusieurs solutions pour lancer des commandes en arrière plan sur Linux.

Comment exécuter des commandes et processus en arrière-plan sur Linux

Avec le caractère &

Ajoutez l’esperluette à la fin d’une commande pour placer la commande en arrière-plan.
Voici un exemple où on télécharger un fichier en arrière-plan avec wget :

wget https://exemple.com/grosfichier.zip &
[1] 21348

La sortie “[1] 21348” indique que le processus de téléchargement s’exécute en arrière-plan avec un ID de travail de “1” et un PID de “21348”.

Ensuite, pour lister les processus exécutés en arrière-plan, utilisez la commande jobs :

jobs -l

Enfin, la commande fg permet de rappeler le processus :

fg <job-id>

Toutefois, cela ne suffit pas, si vous souhaitez que l’exécution du processus perdure après l’arrêt du terminal ou de la session.
En d’autres termes, si vous vous déconnectez de votre terminal, tous les travaux en cours seront interrompus.
Pour éviter cela, vous pouvez passer l’option -h à la commande disown. Cette option marque chaque jobID pour que le SIGHUP ne soit pas envoyé au job si l’interpréteur de commandes reçoit un SIGHUP. La syntaxe est la suivante :

disown -h <job-id>

Imaginons que vous souhaitez exécuter une mise à jour du système avec apt-get en root en arrière-plan et qui ne s’arrête pas si la session se termine.
Voici les commandes à utiliser :

sudo -i # Pour devenir root
apt-get upgrade &> /root/system.update.log & # Mise à jour du système avec redirection de la sortie dans un fichier
disown -h # Marquer apt-get pour que SIGHUP ne soit pas envoyé à la sortie
exit # On quitte le shell root

Avec la commande Nohup

La commande nohup de Linux est un outil puissant qui vous permet d’exécuter vos processus en arrière-plan. Elle est extrêmement utile lorsque vous souhaitez exécuter un processus qui prend beaucoup de temps et que vous ne voulez pas occuper votre terminal ou votre session pendant toute cette durée.

nohup wget https://exemple.com/largefile.zip &

Avec Screen

La commande screen est un gestionnaire de fenêtres plein écran qui multiplexe un terminal physique entre plusieurs processus. Elle vous permet d’exécuter plusieurs sessions de terminal dans une même fenêtre et de passer de l’une à l’autre sans effort.

Voici comment démarrer une nouvelle session nommée ‘nom_session” avec la commande screen :

screen -S nom_session

Pour reprendre la session, utilisez l’option -r en indiquant le nom de la session :

screen -r nom_session

Avec Tmux

Tmux, abréviation de “terminal multiplexer”, est une autre commande qui vous permet d’exécuter plusieurs sessions de terminal dans une seule fenêtre. Elle est similaire à screen, mais offre plus de fonctionnalités et une interface plus moderne.

tmux new -s ma_session

Dans cet exemple, nous démarrons une nouvelle session tmux nommée ‘ma_session’. La sortie “[detached (from session ma_session)]” indique que la session est en cours d’exécution en arrière-plan.

Pour s’attacher à la session, utilisez la commande attach :

tmux attach -t ma_session

L’article Linux : exécuter des commandes en arrière-plan est apparu en premier sur malekal.com.

A severe vulnerability (CVE-2024-3094) has been discovered in XZ Utils (5.6.0 or 5.6.1), a commonly used compression format. The vulnerability allows attackers to gain root access through SSH. XZ Utils is used in many Linux distributions; it is also available for Windows and has been incorporated into many other programs. Attackers can install programs, manipulate data, or create new accounts with full root privileges. While there are no reports of exploits in the wild, the potential impact is profound, and most Linux distributions have issued warnings. In this post, you will learn how to determine if your systems are affected and what to do if they are.

Firmware security firm Binarly has released a free online scanner to detect Linux executables impacted by the XZ Utils supply chain attack, tracked as CVE-2024-3094. [...]

Dans cet article, nous allons revenir sur la porte dérobée présente dans la bibliothèque XZ Utils afin d'évoquer les distributions Linux affectées, ainsi qu'un outil permettant de vérifier si votre serveur est affecté ou non !

Pour rappel, la bibliothèque de compression de données XZ Utils, correspondante au paquet "liblzma", est victime d'une compromission de la chaîne d'approvisionnement (supply chain attack) : les deux dernières versions (5.6.0 et 5.6.1) contiennent du code malveillant qui permet de déployer une porte dérobée sur le système. Cette backdoor offre la possibilité de se connecter en SSH sur la machine et d'exécuter du code malveillant sans être authentifié.

Cette vulnérabilité est associée à la référence CVE-2024-3094 et elle est considérée comme critique (score CVSS v3.1 de 10 sur 10).

• Article : Linux et la porte dérobée XZ Utils

CVE-2024-3094 : ma machine est-elle vulnérable ?

Tout d'abord, sachez que les versions vulnérables de XZ Utils sont utilisées par certaines distributions Linux en cours de développement, dont voici la liste :

• Fedora Rawhide
• Fedora 41
• Debian Sid (les versions testing, unstable et expérimentale de Debian)
• openSUSE Tumbleweed
• openSUSE MicroOS

Par ailleurs, si vous utilisez Kali Linux, votre machine peut être affectée : "Si vous avez mis à jour votre installation Kali le 26 mars ou après, mais avant le 29 mars, il est crucial d'appliquer les dernières mises à jour aujourd'hui pour résoudre ce problème.", peut-on lire sur cette page du site de Kali Linux.

Désormais, les mainteneurs de ces différentes distributions ont fait le nécessaire pour revenir sur une version non vulnérable. Cependant, c'est-à-vous de faire la manipulation pour revenir en arrière si votre machine est affectée.

Pour vérifier si votre machine est affectée ou non, vous pouvez exécuter le script Bash "CVE-2024-3094 Checker" disponible sur GitHub. Ce script communautaire fonctionne sur les différentes distributions et va regarder qu'elle est la version de XZ Utils installée sur votre machine, et vous indiquer, si oui ou non, vous êtes vulnérable.

Par exemple, sur une machine Debian, la commande suivante est utilisée pour effectuer la vérification :

dpkg -l | grep "xz-utils"

Pour rappel, vous ne devez pas utiliser les versions 5.6.0 et 5.6.1 de XZ Utils, car elles sont compromises. D'ailleurs, si vous utilisez une distribution où le gestionnaire de paquets Apt est utilisé (Debian, par exemple), le script vous proposera de revenir sur la version stable non compromise la plus récente, à savoir la 5.4.6. Enfin, il est également recommandé de lire le bulletin de sécurité publié sur le site de la distribution que vous utilisez.

The post Porte dérobée dans XZ Utils : vérifiez si votre machine Linux est vulnérable ! first appeared on IT-Connect.

Grosse alerte de sécurité : la bibliothèque "liblzma" utilisée par de nombreuses distributions Linux est victime d'une compromission de la chaîne d'approvisionnement : les dernières versions contiennent du code malveillant qui permet de déployer une porte dérobée sur le système. Faisons le point sur cette menace.

La bibliothèque liblzma appelée aussi XZ Utils est présente dans de nombreuses distributions Linux, notamment Arch Linux, Fedora, Debian, OpenSUSE, Alpine Linux, etc... Il s'agit d'une bibliothèque de compression de données susceptible d'être utilisées par d'autres applications.

Il s'avère que deux versions de la bibliothèque liblzma sont impactées par une attaque de type supply chain : 5.6.0 ou 5.6.1. La version 5.6.0 date de fin février tandis que la version 5.6.1 a été publiée le 9 mars 2024. Ces deux versions du paquet XZ contiennent du code malveillant qui a été très bien dissimulé par les auteurs de cette attaque, par l'intermédiaire d'un fichier m4 avec du code obfusqué. Il est visible uniquement lorsque le paquet est téléchargé en intégralité, donc il est invisible sur Git, par exemple.

Andres Freund, ingénieur logiciel chez Microsoft, a fait la découverte de ce problème de sécurité en menant des investigations sur une machine Debian Sid, après avoir constaté que les connexions SSH étaient anormalement longues.

Si une version compromise du paquet XZ est installée sur une machine, alors une porte dérobée est également déployée. Celle-ci offre un accès distant à l'attaquant qui pourrait se connecter à votre machine par l'intermédiaire d'une connexion SSH, sans avoir besoin de connaître vos identifiants (car il y a un lien entre systemd et liblzma).

Sachez que ceci est considéré comme une vulnérabilité et que la référence CVE pour cette faille de sécurité critique est la suivante : CVE-2024-3094. Sans surprise, un score CVSS v3.1 de 10 sur 10 a été associé à cette vulnérabilité.

Quels sont les systèmes affectés ?

Même si plusieurs distributions telles que Debian, Fedora ou encore Arch Linux sont concernées, ceci n'affecte pas toutes les versions. En effet, ceci concerne avant tout les versions en cours de développement, dont Debian Sid qui est la future version stable de Debian.

Pour Fedora, sachez que Fedora Rawhide et Fedora 41 sont affectées par ce problème de sécurité. Au sein du bulletin de sécurité de Red Hat, nous pouvons également lire ceci : "Aucune version de Red Hat Enterprise Linux (RHEL) n'est concernée.", ce qui n'est pas surprenant.

Potentiellement, tout autre système avec le paquet XZ en version 5.6.0 ou 5.6.1 est également affecté, donc vérifiez vos machines. Dans ce cas, il convient d'effectuer un downgrade vers la version 5.4.6.

Cette commande doit permettre d'obtenir la version :

dpkg -l | grep "xz-utils"

Pour approfondir le sujet, vous pouvez lire cet article intéressant qui donne des détails techniques supplémentaires, ainsi que l'origine de cette compromission : un nouveau développeur qui est venu épauler le créateur de la bibliothèque XZ Utils.

The post Alerte de sécurité Linux : une porte dérobée a été intégrée dans XZ Utils ! first appeared on IT-Connect.

Aïe aïe aïe, ça sent le roussi ! Une vilaine backdoor a été dénichée dans l’utilitaire xz Utils, un outil de compression présent dans un paquet de distributions Linux. Et attention, c’est du lourd : cette saloperie est capable de contourner l’authentification SSH et donc de permettre un accès non autorisé aux systèmes. Autant vous dire que c’est la panique générale !

La faille a été découverte le 29 mars 2024 par un dénommé Andres Freund, un développeur qui a flairé l’embrouille dans les versions 5.6.0 et 5.6.1 de xz Utils dont la liblzma. La backdoor se planque dans les fichiers de test bad-3-corrupt_lzma2.xz et good-large_compressed.lzma, et utilise un script appelé par build-to-host.m4 pour s’incruster dans le processus de build. Cerise sur le gâteau, elle exploite le mécanisme IFUNC de la glibc pour détourner l’authentification d’OpenSSH à l’exécution. Machiavélique !

En fait, le code malveillant ne se trouve pas directement dans le dépôt mais uniquement dans les archives de release 5.6.0 et 5.6.1. Un examen du code source ne révèle donc rien de suspect, il faut télécharger les tarballs pour chopper la version vérolée. Vicieux !

Mais le plus dingue dans l’histoire, c’est que cette backdoor a été commitée par un certain JiaT75, aka Jia Tan, l’un des deux principaux développeurs de xz Utils, qui bosse sur le projet depuis 2022 ! En fait, ce type a commencé par introduire une vulnérabilité dans libarchive en 2021 avant de s’attaquer à xz.

Quand des problèmes sont apparus avec Valgrind sur la liblzma juste après la release 5.6.0 en février, ce cher Jia Tan a suggéré qu’il s’agissait d’un bug de GCC. Il a même poussé un commit bidouillant le code pour contourner les erreurs Valgrind, en pointant vers un rapport de bug GCC n’ayant rien à voir. À ce stade, il n’y a plus de doute possible : le compte JiaT75 est contrôlé par un acteur malveillant, point barre. Reste à savoir si Jia Tan a toujours été un méchant ou si son compte a été compromis.

Depuis son entrée en scène, JiaT75 n’a pas chômé. Infrastructure de test vérolée, prise de contrôle progressive du projet, jusqu’à tenter de refiler la version backdoorée à Debian, Fedora et Ubuntu. Et dire que GitHub a attendu le dernier moment pour lui mettre le grappin dessus et bloquer l’accès au dépôt, bien joué les gars. Heureusement qu’Andres veillait au grain, sinon on n’imagine même pas le bordel.

Parce que oui, ces versions 5.6.0 et 5.6.1 ont failli se faufiler dans les releases stables des principales distribs. Par chance, elles ne se sont glissées que dans quelques bêtas, notamment Fedora 40, Fedora Rawhide et les distribs testing, unstable et experimental de Debian. Même Arch Linux y a eu droit dans une release stable. Bref, ça a failli faire très mal !

Comme le souligne Will Dormann, un analyste en sécu chez Analygence, si la backdoor n’avait pas été repérée à temps, ça aurait pu être une véritable hécatombe. Les systèmes les plus à risque sont ceux qui tournent avec glibc et xz 5.6.0 ou 5.6.1, surtout s’ils exposent un serveur SSH public. Là c’est défcon 1, faut mettre à jour TOUT DE SUITE MAINTENANT ! Pour les autres, pas de panique, mais mieux vaut jouer la prudence et updater fissa. Plus d’infos sur les systèmes touchés et comment les patcher dans cet article.

Mais qu’est-ce que SSH vient faire dans cette galère ? En fait, beaucoup de distribs Linux patchent sshd pour ajouter des fonctionnalités systemd, et libsystemd utilise la liblzma. Résultat, le code d’initialisation de liblzma est exécuté au démarrage de sshd. Et devinez quoi ? La backdoor vérifie si le programme lancé est /usr/bin/sshd et remplace des fonctions comme RSA_public_decrypt, utilisée pour valider les clés SSH. On vous laisse imaginer la suite… Une analyse complète est en cours, attendez-vous à d’autres révélations dans les prochains jours.

Depuis, c’est le branle-bas de combat. Les mainteneurs de Fedora et Debian se sont empressés de retirer les versions vérolées et de revenir à une release clean de xz Utils. Et les utilisateurs sont appelés à vérifier s’ils sont affectés en utilisant un script de détection mis à dispo par Andres himself. Mais le mal est fait et la confiance est ébranlée.

L’avenir du projet xz est incertain et il faut s’attendre à un ou plusieurs hard forks et à un gros nettoyage. Pour plus d’infos, jetez un œil aux alertes de sécurité de Redhat et Debian, ainsi qu’au thread oss-security sur le sujet.

Cet épisode rappelle cruellement qu’en matière de sécurité, la vigilance est mère de sûreté, même au sein des projets open source. Il met aussi en lumière la fragilité de notre écosystème, où des pans entiers reposent sur les épaules fatiguées de quelques mainteneurs débordés. Il est grand temps d’avoir une prise de conscience collective et de mieux soutenir ces projets critiques. Parce que mine de rien, on parle quand même des fondations qui font tourner une bonne partie d’Internet et des infrastructures critiques.