Unbreakable Enterprise Kernel 8.2 is now available for Oracle Linux 9 and 10, featuring a Linux 6.12 LTS base and upstream security updates.

The post Oracle Releases Unbreakable Enterprise Kernel 8.2 Based on Linux 6.12 LTS appeared first on Linux Today.

49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.

Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.

C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.

En fouillant le code du noyau XNU d'Apple (qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.

Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.

Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !

Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.

Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !

Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.

Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).

Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :

boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"

Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.

Enfin !

Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.

D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.

Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers USBGuard pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !

Mais alors pourquoi lancer ça maintenant ?

Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.

Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme USBRip (un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.

On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !

Bref, va falloir garder un œil là-dessus.

Source

Et si je vous disais qu'il existe un scheduler Linux qui prend ses décisions en fonction de l'astrologie. Non, c'est pas une blague, le premier avril c'est pas avant quelques jours. Ce scheduler s'appelle scx_horoscope et c'est un vrai module BPF qui se charge dans le noyau et qui décide quel processus a droit au CPU selon la position des planètes dans le zodiaque. Et ça fonctionne pour de vrai !

En gros, le principe c'est ça : chaque planète du système solaire se voit attribuer un domaine. Le Soleil gère les processus critiques (PID 1, init), la Lune s'occupe de vos shells et éditeurs de texte, Mars prend en charge la compilation et l'encodage vidéo, et Jupiter veille sur vos bases de données. Les positions sont alors calculées en temps réel grâce au crate Rust astro, donc oui, c'est de la vraie mécanique céleste, pas un random(). En fait, le binaire calcule les éphémérides géocentriques pour déterminer dans quel signe se trouve chaque planète à l'instant T.

L'outil en train de déterminer le bulletin météo cosmique de votre CPU

Et c'est là que ça devient franchement tordu car chaque signe du zodiaque est associé à un élément (Feu, Air, Eau, Terre) qui modifie les priorités CPU. Votre compilateur tourne pendant que le Soleil est dans le Bélier ? Hop, boost x1.5 pour les tâches CPU-intensive. Par contre, si c'est un signe d'Eau qui domine... 0.6x sur la compilation. Pas de bol ! Et si en plus une planète est en rétrograde (genre elle recule dans le ciel), tous les time slices sont divisés par deux. Votre make -j8 se fera par exemple interrompre deux fois plus souvent, parce que Vénus fait sa diva.

Le module utilise sched_ext, le framework du kernel Linux (6.12 minimum) qui permet de coder des ordonnanceurs en espace utilisateur via eBPF. Et c'est pas un proof-of-concept bidon, car ça charge vraiment dans le noyau. Un cargo build --release, un sudo devant, et hop votre machine tourne au rythme des astres. Y'a même un mode --cosmic-weather qui affiche un bulletin météo cosmique avec les phases de la Lune et les positions planétaires du moment.

Notez par exemple que la pleine lune booste les tâches interactives de 40%. Donc si vous tapez du code à 3h du mat' un soir de pleine lune, votre terminal sera techniquement plus réactif. Coïncidence ? Bah non, c'est Cyber Madame Soleil qui gère !

Le projet propose aussi un flag --ophiuchus pour activer le 13e signe du zodiaque (celui que l'Union Astronomique Internationale reconnaît mais que les astrologues ignorent royalement qui s'appelle en français Serpentaire).

Ce projet est donc clairement à classer dans la catégorie "parce qu'on peut" mais le niveau technique est loin d'être ridicule puisque c'est codé en Rust, en C pour la partie BPF, que ça embarque de vrais calculs d'éphémérides, et une intégration kernel qui tient la route. Et les issues sur le GitHub sont un festival... quelqu'un a par exemple demandé le support des éclipses solaires, tandis qu'un autre veut du chaos pendant les éruptions solaires. Internet à son meilleur ! Top of the top de l'indispensable inutile !

Bref, si vous voulez que Jupiter booste vos bases de données ou votre génération de site statique, foncez . Et merci à Camille Roux pour le partage !

There are several ways to find out which version of Linux you’re running on your system, including your distribution name, architecture, kernel version, and other important system information that you should have at your fingertips.

In this guide for Linux users, I’ll show you how to find your Linux system’s operating system version from the command line. While this may seem like a straightforward task, having a solid understanding of your system is always recommended for several important reasons.

The post How to Check Linux OS Name and Kernel Version [6 Quick Methods] appeared first on Linux Today.

• lien nᵒ 1 : Site Officiel
• lien nᵒ 2 : Code Source (GitHub)
• lien nᵒ 3 : Documentation JemaOS

Commentaires : voir le flux Atom ouvrir dans le navigateur